Method of processing non-real time service and broadcast receiver

ABSTRACT

A method of receiving and processing a broadcast signal including a Non-Real Time (NRT) service and a broadcast receiver are disclosed herein. A method of processing a Non-Real Time (NRT) service in a broadcast receiver, the method comprises receiving and processing a signaling information table including access information of the NRT service, receiving data of the NRT service based on the signaling information table in non-real time and storing the received data of the NRT service in a storage medium, extracting service information including service type of the NRT service and detail information of the NRT service from the signaling information table, and controlling processes of the NRT service based on the extracted service information.

This application claims the benefit of U.S. Provisional Application No.61/115,888 filed on Nov. 18, 2008, 61/121,178 and 61/121,181 filed onDec. 9, 2008, 61/138,494 filed on Dec. 17, 2008, 61/153,985 and61/153,973 filed on Feb. 20, 2009, 61/161,416 filed on Mar. 19, 2009 and61/179,005 filed on May 17, 2009

BACKGROUND OF THE INVENTION

1. The Field

The present disclosure relates to a method for processing non-real timeservice and broadcast receiver thereof.

2. Description of the Related Art

A digital television (DTV) can provide video and audio services whichare conventional TV services, but can also provide various otherservices. For example, the DTV can provide an Electronic Program Guide(EPG) or the like to the user and can simultaneously provide broadcastservices received through 2 or more channels. Especially, the number ofservices that a reception system can provide has been significantlyincreased since the reception system has been equipped with alarge-capacity storage device and has been connected to the Internet ordata communication channels which enable bidirectional communication.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a method of receiving anon-real time service and a broadcast receiver thereof.

Another object of the present invention is to provide a method ofsignaling service information which includes type and detailedinformation relating to a non-real time service and the broadcastreceiver thereof.

Another object of the present invention is to provide a method ofprocessing a non-real time service according to service information andthe broadcast receiver thereof.

Additional advantages, objects, and features of the invention will beset forth in part in the description which follows and in part willbecome apparent to those having ordinary skill in the art uponexamination of the following or may be learned from practice of theinvention. The objectives and other advantages of the invention may berealized and attained by the structure particularly pointed out in thewritten description and claims hereof as well as the appended drawings.

To achieve the above objectives according to an embodiment of thepresent invention to process a non-real time service of a broadcastreceiver, the steps may include receiving and processing a signalinginformation table including access information of the NRT service,receiving data of the NRT service based on the signaling informationtable in non-real time and storing the received data of the NRT servicein a storage medium, extracting service information including servicetype of the NRT service and detail information of the NRT service fromthe signaling information table, and controlling processes of the NRTservice based on the extracted service information.

The service information may further include a user control fieldindicating whether the user is authorized to manage a file included inthe NRT service, a field indicating codec information of the NRTservice, and a field indicating an expiration period of the NRT servicestored in the storage.

The service information includes a field indicating when the NRT serviceis a web service according to the service type, whether the web serviceis supported by a web browser in the broadcast receiver.

The service information includes a field providing a display locationand size within the display of the NRT service.

If the NRT service is a Fixed NRT service, a file and the signalinginformation table included in the NRT service is received in packetizedInternet Protocol (IP), packetized addressable section, and packetizedMoving Picture Experts Group-2 (MPEG-2) Transport Packet (TP).

If the NRT service is a Mobile NRT service, a file and the signalinginformation table included in the NRT service is received in packetizedIP included in an Ensemble.

A broadcast receiver for receiving a broadcast signal including aNon-Real Time (NRT) service includes a first processing unit, a secondprocessing unit, and a service manager. The first processing unitreceives and processes a signaling information table including accessinformation of the NRT service. The second processing unit receives dataof the NRT service based on the signaling information table in non-realtime and stores the received data of the NRT service in a storagemedium. The service manager extracts service information includingservice type of the NRT service and detail information of the NRTservice from the signaling information table and controls processes ofthe NRT service based on the extracted service information.

The broadcast receiver further includes a presentation manager to outputthe detail information of the service type of the NRT service and detailinformation of the NRT service in a guide display.

Other objects, features, and advantages of the present invention will beapparent through a detailed description of the embodiments withreference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are included to provide a furtherunderstanding of the invention and are incorporated in and constitute apart of this application, illustrate embodiment(s) of the invention andtogether with the description serve to explain the principle of theinvention. In the drawings:

FIG. 1 illustrates a conceptual diagram of providing a real-time (RT)service and a non-real time (NRT) service;

FIG. 2 is a diagram illustrating the relationship between an NRTservice, content items, and files;

FIG. 3 illustrates an embodiment of a protocol stack for a fixed NRTservice according to the present invention;

FIG. 4 illustrates an embodiment of a bit stream syntax structure of avirtual channel table according to the present invention;

FIG. 5 illustrates an embodiment of service_type field values in thevirtual channel table of FIG. 4 and respective meanings of the values;

FIG. 6 illustrates another embodiment of values allocated to aservice_type field in the virtual channel table of FIG. 4 and respectivemeanings of the values;

FIG. 7 illustrates an embodiment of a bit stream syntax structure of adata service table (DST) of the present invention;

FIG. 8 illustrates an embodiment of a procedure for obtaining accessinformation of an IP stream that carries an NRT service signalingchannel using a PSI/PSIP table according to the present invention;

FIG. 9 is a flowchart illustrating a procedure for obtaining accessinformation of an IP stream that carries an NRT service signalingchannel using a PSI/PSIP table according to an embodiment of the presentinvention;

FIG. 10 and FIG. 11 illustrate a bit stream syntax structure of aNon-Real Time Service Table (NST) according to the present invention;

FIG. 12 illustrates a bit stream syntax structure of acomponent_descriptor( ) according to an embodiment of the presentinvention;

FIG. 13 illustrates a bit stream syntax of FLUTE file delivery datausing the component_descriptor( ) of FIG. 12;

FIG. 14 illustrates a bit stream syntax structure ofNRT_service_info_descriptor( ) according to an embodiment of the presentinvention;

FIG. 15 illustrates the meaning of the allocated values to theapplication_type field in FIG. 14;

FIGS. 16( a) through 16(d) illustrate examples real time service andnon-real time service shown in the same display screen according to thepresent invention;

FIG. 17 illustrates a flowchart processing NRT service using the serviceinformation according to the present invention;

FIG. 18 and FIG. 19 illustrate a bit stream syntax structure of aNon-Real Time Information Table (NRT-IT) according to an embodiment ofthe present invention;

FIG. 20 is a block diagram illustrating a broadcast receiver thatprovides a Fixed NRT service according to an embodiment of the presentinvention;

FIG. 21 illustrates an embodiment of a protocol stack for a mobile NRTservice according to the present invention;

FIG. 22 illustrates an embodiment of data group structure according tothe present invention;

FIG. 23 illustrates an embodiment of a RS frame structure including amobile NRT service according to the present invention;

FIG. 24 illustrates a Mobile Handheld (M/H) frame structure forreceiving and transmitting mobile service data according to the presentinvention;

FIG. 25 illustrates a data transmitting structure of physical layeraccording to the present invention;

FIG. 26 illustrates a bit stream syntax structure of a Service Map Table(SMT) according to the present invention; and

FIG. 27 illustrates a block diagram illustrating a broadcast receiverthat provides a Mobile NRT service according to an embodiment of thepresent invention;

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred embodiments of the invention, which can achieve the aboveobjects, will now be described with reference to the accompanyingdrawings. The configuration and operation of the invention, illustratedin the drawings and described below with reference to the drawings, willbe described using at least one embodiment without limiting the spiritand the essential configuration and operation of the invention.

Although most terms of elements in the present invention have beenselected from general ones widely used in the art taking intoconsideration their functions in the invention, the terms may be changeddepending on the intention or convention of those skilled in the art orthe introduction of new technology. Some terms have been arbitrarilyselected by the applicant and their meanings are explained in detail inthe following description as needed. Thus, the definitions of the termsused in the invention should be determined based on the whole content ofthis specification together with the intended meanings of the termsrather than their simple names or meanings.

The term real time (RT) service used in the present invention actuallymeans the real-time service. In other words, it is restricted in time.On the other hand, non-real time (NRT) service refers to non-real time,not RT service. Thus, NRT service is not restricted in time. Further thedata used in NRT service is referred to as NRT service data.

A broadcast receiver according to the present invention receives NRTservice through terrestrial, cable, internet, and the like.

The NRT service is stored in the broadcast receiver and then it isdisplayed through a display according to a time specified by the user orat the user's request. The NRT service is received and stored in a fileformat according to an embodiment. In an embodiment, the storage is aninternal HDD attached to the inside of the broadcast receiver. Inanother embodiment, the storage may be Universal Serial Bus (USB) memoryor an external HDD connected externally with the broadcast receivingsystem.

In order to receive and store the files configuring the NRT service andprovide service to the user, signaling information or NRT servicesignaling data according to the present invention.

FIG. 1 illustrates a conceptual diagram of how a RT and an NRT serviceare provided.

The broadcast station, following the conventional method, transmits thecurrent terrestrial broadcast (or mobile broadcast) RT service. At thisjuncture, the broadcast station may provide NRT service using the extrabandwidth or a specific bandwidth left after sending the RT service.Thus, RT service and NRT service are transmitted through a same or adifferent channel. Therefore, a broadcast receiver can be divided intoRT service and NRT service, and in order to provide the user with theNRT service when needed, NRT service signaling information (or NRTservice signaling data) is required. The NRT service signalinginformation (or NRT service signaling data) will be described below indetail.

For example, a broadcast station can transmit broadcast service data inreal time and transmit news clips, weather information, advertisements,push VOD, or the like in non-real time. The NRT service many not onlyprovide such news clips, weather information, advertisements, and pushVOD, but may also provide specific clips and detailed information onspecific program from a real-time broadcast service.

A conventional broadcast receiver (i.e., a legacy device) can receiveand process RT services but cannot receive and process NRT services.Thus, it is a principle that the process of the conventional broadcastreceiver (i.e., a legacy device) is not affected by NRT stream includedin the transmission of RT service. In other words, the conventionalbroadcast receiver does not have a method of handling the NRT serviceeven if it is received.

However, the broadcast receiver (i.e., an NRT device) according to anembodiment of the present invention can combine NRT services and RTservices to provide a variety of services to the user compared to theconvention receiver.

In an embodiment, one NRT service according to the present inventionincludes one or more content item (or content or NRT content) and onecontent item includes one or more files as shown in FIG. 2. The terms“file” and “object” have the same meaning in the description of thepresent invention.

The content item is the minimum unit that can be presentedindependently. For example, when a news program, which includes aneconomic news section, a political news section, and a life newssection, is provided in non-real time, the news program may be an NRTservice and each of the economic news section, the political newssection, and the life news section may be the content item. And each ofthe economic news section, the political news section, and the life newssection may include at least one file.

In the present invention, depending on acquiring the IP datagram, theservice may be divided into Fixed NRT service and Mobile NRT service.The Fixed NRT service, especially, is provided through fixed broadcastreceiver, and the Mobile NRT service is provided through mobilebroadcast receiver. In the present invention, Fixed NRT service will beexplained first and then Mobile NRT service will be explained.

Fixed NRT Service

In an embodiment of the present invention, for fixed NRT service, thefile-type NRT service is packetized according to an IP scheme in the IPlayer and then transmitted through a specific virtual channel in anMPEG-2 TS format.

Thus, Fixed NRT service may be transmitted through the same broadcastchannel as the RT service or through an exclusive broadcast channel in aMPEG-2 TS packetized format. In order to identify the NRT service, aunique PID is allocated in the TS packet of the NRT service data whentransmitted. In an embodiment of the present invention, the IP based NRTservice data is transmitted in MPEG-2 TS packetized format.

The NRT service signaling data required to receive the NRT service datais transmitted through an NRT service signaling channel. The NRT servicesignaling channel is transmitted through a specific IP stream in the IPlayer. Here, the IP stream is also packetized into an MPEG-2 TS packetfor transmission. The NRT service signaling data transmitted through anNRT service signaling channel includes NRT Service Map Table (NST) andNRT Information Table (NRT-IT). In an embodiment of the presentinvention, the NST provides the access information of at least one NRTservice and at least one content item/file that forms NRT services thatoperate in the IP layer. In one embodiment of the present invention,NRT-IT provides detailed information of the content item/file that formsNST service. In the present invention, the NST and the NRT-IT may bereferred to as Signaling Information Table for Fixed NRT service.

FIG. 3 illustrates a diagram for a protocol stack of a fixed NRT serviceconfigured according to an embodiment of the present invention.

In an embodiment of the present invention, for fixed NRT service, thefile-type NRT service is packetized according to an IP scheme in the IPlayer and then transmitted through a specific virtual channel in anMPEG-2 TS format.

In an embodiment of the present invention, as an example of the MPEG-2based Program Specific Information/Program and System InformationProtocol (PSI/PSIP) table, the presence of the NRT service may besignaled through the virtual channel in the Virtual Channel Table (VCT).

In an embodiment of the present invention, the NRT service signalingchannel that transmits NRT service signaling data which signals theaccess information of the IP based NRT service is transmitted in anMPEG-2 TS format after being packetized according to an IP stream in theIP layer through a specific virtual channel.

More specifically, in the broadcast station, NRT content/files arepacketized according to a file transfer protocol scheme and are againpacketized according to an Asynchronous Layered Coding/Layered CodingTransport (ALC/LCT) scheme as shown in FIG. 3. The packetized ALC/LCTdata is again packetized according to a UDP scheme and the packetizedALC/LCT/UDP data is again packetized into ALC/LCT/UDP/IP data accordingto an IP scheme. Herein, the ALC/LCT/UDP/IP data includes FileDescription Table (FDT) containing information about FLUTE session. Inthe present invention, the packetized ALC/LCT/UDP/IP data is referred toas an “IP datagram” for ease of explanation.

In addition, NRT service signaling data required to receive the NRTcontent/files is transmitted through an NRT service signaling channel.Here, the NRT service signaling channel is packetized according to aUser Datagram Protocol (UDP) scheme and the packetized UDP data is againpacketized into UDP/IP data according to an IP scheme. In the presentinvention, the UDP/IP data is also referred to as an “IP datagram” forease of explanation. In an embodiment, multicast of the NRT servicesignaling channel is achieved after being encapsulated in an IP datagramhaving a well-known IP destination address and a well-known destinationUDP port number.

In an embodiment of the present invention, IP datagrams of the NRTservice signaling channel and the NRT service are encapsulated in anaddressable section structure and again packetized in an MPEG-2 TSformat. So, one addressable section structure has a format in which asection header and a CRC checksum are added to one IP datagram. Thisaddressable section structure format complies with a Digital StorageMedia Command and Control (DSM-CC) section format for private datatransmission. Thus, the addressable section is also referred to as a“DSM-CC addressable section.” A 188-byte MPEG-2 TS packet can be createdby dividing the addressable section data into 184-byte units and addinga 4-byte MPEG header to each 184-byte unit. At this time, a valueallocated to a PID of the MPEG header is a unique value that canidentify TS packets that carry the NRT service signaling channel and theNRT service.

Program Specific Information (PSI) and Program and System InformationProtocol (PSIP) table section data is also packetized into MPEG-2 TSpackets.

An embodiment of the PSI table may include a Program Map Table (PMT), aProgram Association Table (PAT), or the like and an embodiment of thePSIP table may include a Virtual Channel Table (VCT), a System TimeTable (STT), a Rating Region Table (RRT), an Extended Text Table (ETT),a Direct Channel Change Table (DCCT), a Direct Channel Change SelectionCode Table (DCCSCT), an Event Information Table (EIT), and a MasterGuide Table (MGT).

The MPEG-2 TS packets are modulated according to a predeterminedtransmission scheme, for example, a VSB transmission scheme, in aphysical layer and are then transmitted to the reception system.

In an embodiment of the present invention, the transmission of an NRTservice is determined by signaling through a PSI/PSIP table. Forexample, whether or not an NRT service is transmitted is signaled in aVirtual Channel Table (VCT).

FIG. 4 illustrates a syntax structure of the Virtual Channel Table (VCT)section according to an embodiment.

The VCT section, taking information about the virtual channel forexample, transmits information of channel information for channelselection and PID information for receiving audio and/or video. Thus,when the VCT section is parsed, the PID of the audio and video of thebroadcast program transmitted within the channel along with the channelnumber and channel name is known.

The VCT section syntax includes at least one of table_id field,section_syntax_indicator field, private_indicator field, section_lengthfield, transport_stream id field, version_number field,current_next_indicator field, section_number field, last_section_numberfield, protocol_version field, num_channels_in_section field.

The VCT section syntax further includes first ‘for’ loop (virtualchannel loop) which repeats for the number indicated in thenum_channels_in_section field value, the first loop includes at leastone of short_name field, major_channel_number field,minor_channel_number field, modulation_mode field, carrier_frequencyfield, channel_TSID field, program_number field, ETM_location field,access_controlled field, hidden field, service_type field, source_idfield, descriptor_length field, or second ‘for’ loop which repeats forthe number of the descriptors included in the first loop. For theconvenience of explanation in the present invention, the second loop isreferred to as the first descriptor loop. The descriptor( ) included inthe first descriptor loop is a descriptor applied in each virtualchannel.

The VCT section syntax may further include a third ‘for’ loop whichrepeats for the number of value indicated byadditional_descriptor_length field and the number of descriptor added inthe VCT section. For the convenience of explanation in the presentinvention, the third loop is referred to as the second descriptor loop.The additional_descriptors( ) included in the second descriptor loop isapplied to all the descriptors described in the virtual channel of theVCT section.

A table_id field illustrated in FIG. 4 indicates a unique identifier oridentification (ID) which identifies that the information transmittedthrough the table is VCT. More specifically, the table_id fieldindicates a value informing that the table corresponding to this sectionis a VCT. For example, a 0xC8 value may be given to the table_id field.

A version_number field indicates the version number of the VCT, thesection_number field indicates the number of this section, and thelast_section_number field indicates the number of the last section of acomplete VCT. The num_channels_in_section field designates the number ofthe overall virtual channel existing within the VCT section.

A short_name field in the first ‘for’ loop indicates the name of avirtual channel. The major_channel_number field indicates a ‘major’channel number associated with the virtual channel defined within thefirst loop and the minor_channel_number field indicates ‘minor’ channelnumber. Thus, each channel number should be connected to the major andminor channel numbers, and the major and minor channel numbers are usedas user reference numbers for the corresponding virtual channel.

A short_name field in the first ‘for’ loop indicates the name of avirtual channel. The major_channel_number field indicates a ‘major’channel number associated with the virtual channel defined within thefirst loop and the minor_channel_number field indicates ‘minor’ channelnumber. Thus, each channel number should be connected to the major andminor channel numbers, and the major and minor channel numbers are usedas user reference numbers for the corresponding virtual channel.

A service_type field indicates the service type within the correspondingvirtual channel.

In an embodiment, the virtual channel may include at least one RTservice and at least one NRT service including audio and/or video.

In this case, service type values may be allocated as shown in FIG. 5and a value of 0x04 representing an ATSC-data-only service may be usedto indicate that an NRT service is provided through the virtual channel.

In another embodiment, the virtual channel may only include one or moreNRT service. In such a case, as shown in FIG. 6, a new service_typefield value of 0x08 may be defined to indicate that an NRT service isprovided through the virtual channel.

A source_id field indicates a program source connected to thecorresponding virtual channel.

The term “source” refers to a specific source such as a video, text,data or audio source. The source_id field has a unique value in atransport stream in which a VCT is transmitted.

On the other hand, data service table (DST) may be received through PIDincluded in the service_location_descriptor of the VCT, and through theDST, the types of the application and the detailed information of thedata broadcast stream transmitted through the channel is known.

In the present invention, NRT application (NRT service) is identifiedthrough the DST.

FIG. 7 illustrates the DST section syntax structure according to anembodiment.

An sdf_protocol_version field (8-bit) indicates the version of theService Description Framework protocol.

An application_count_in_section field (8-bit) indicates the number ofapplications listed within the DST section.

A compatibility_descriptor( ) field indicates that the correspondingstructure includes DSM-CC compatible descriptor. The object is to signalthe compatibility requests of the application of the platform receivedto determine the ability to use the corresponding data service.

An app_id_byte_length field (16-bit) indicates the number of bytes usedto identify the application.

An app_id_description field (16-bit) indicates the format and thesemantics of the next application identification bytes. As described inthe table 1 below, ‘0x0003’ is newly assigned to identify that thecorresponding application is an NRT application. The assigned value of‘0x0003’ is just an exemplary value and the scope of this application isnot limited to the value.

TABLE 1 Value Application Identifier Format 0x0000 DASE application0x0001 ATSC reserved 0x0002 ATSC A/92 Application 0x0003 NRT Application0x0004-0x7FFF ATSC reserved 0x8000-0xFFFF User private

An app_id_byte field (8-bit) describes the byte of the applicationidentifier.

A tap_count field (8-bit) indicates the number of Tap( ) structure usedby the corresponding application.

A protocol_encapsulation field (8-bit) indicates the type of theprotocol encapsulation used to transmit the specific data element inreference with the Tap( ) field.

An action_type field (7-bit) instructs the character of the data inreference with the Tap( ) field.

A resource_location field (1-bit) indicates the location of theassociation_tag field that matches the association_tag value listedwithin the next Tap structure. If the value of the corresponding fieldis ‘0,’ then the matching association_tag exist in the PMT of thecurrent MPEG-2 program. Oppositely, if the value is ‘1,’ then thematching association_tag exists in the DSM-CC Resource Descriptor in theNetwork Resources Table of the corresponding data service.

A Tap( ) field, for example, is defined in a unique structure includingthe following. The tap_id field (16-bit) is used by the application toidentify the data elements. The range of the value of tap_id isdetermined by the app_id_byte fields related to Tap( ) within the DST.The value of tap_id is selected by the data service provider. Further,it is used in application to handle the data elements.

A Use field (16-bit) is used to specify the communication channelreferenced by the association_tag.

An association_tag field (16-bit) uniquely identifies one from thelisted DSM-CC resource descriptor within the Network Resource Table orlisted data elementary stream within the PMT.

A Selector( ) field indicates a unique data element that can be used inthe communication channel referenced by association_tag field or in thedata elementary stream.

A tap_info_length field (16-bit) indicates the number of bytes of thedescriptors of the next field of the corresponding field.

A descriptor( ) field follows the descriptor format.

An app_info_length field (8-bit) indicates number of bytes of thedescriptor of the next corresponding field.

A descriptor( ) field follows the descriptor format. An app_data_lengthfield (16-bit) indicates length of the app_data_byte fields in bytes.

An app_data_byte (8-bit) describes the private data fields differentfrom input parameters associated with the application as 1 byte.

A service_info_length field (8-bit) indicates number of byte unit of thenext descriptors.

A descriptor( ) field follows the descriptor format. Aservice_private_data_length field (16-bit) indicates length of byte unitof the private fields.

A service_private_data_byte field (8-bit) describes the private fieldsas 1 byte.

FIG. 8 illustrates a method in which an NRT service is received andprovided using an ATSC A/90 standard for carrying (or transmitting) adata broadcast stream and an ATSC A/92 standard for transmitting an IPmulticast stream in a broadcast receiver according to the presentinvention.

Namely, information of a stream that constitutes each virtual channel issignaled in an ES_loop of a PMT or a service location descriptor of aVCT. For example, an NRT service stream can be transmitted through thevirtual channel in the case where the service type of the VCT is 0x02(i.e., digital A/V Data), 0x04 (i.e., data only), or 0x08 (i.e., NRTonly service), as shown in FIG. 5 or FIG. 6. At this time, when thestream_type field included in the service location descriptor (or the ESloop of the PMT) has a value allocated 0x95 (i.e., DST transmission),this indicates that a data broadcast is transmitted. A normal A/V istransmitted if the service location descriptor has no value forstream_type field or does not have a value of 0x95 allocated. Therefore,if the stream_type field included in the service location descriptor hasa value of 0x95, the Elementary_PID field value is a PID of a DataService Table (DST). Thus, the DST can be received through theElementary_PID field.

The type of the application and details of a data broadcast streamtransmitted through this channel can be determined through the DST. Inthe present invention, an NRT application (i.e., an NRT service) isidentified using the DST.

That is, an App_id_description field of the DST specifies the format andanalysis of application identification bytes subsequent to this field.In an embodiment of the present invention, ‘0x0003’ is allocated to theApp_id_description field in order to identify the NRT application. Theillustrated value (number) is only an example and does not limit thescope of the present invention.

If the App_id_description field value is ‘0x0003’, anApplication_id_byte value subsequent to this field is a service ID ofthe NRT application. A service ID of the NRT application may have a URIvalue that globally and uniquely identifies the corresponding service.

After the NRT application is identified as described above, a PID of anMPEG-2 TS packet separated from the IP datagram of the NRT servicesignaling channel is located through the Tap information. Then, an IPdatagram that carries the NRT service signaling channel can be obtainedfrom MPEG-2 TS packets having the PID found through the tap informationand NRT service signaling data can be obtained from the obtained IPdatagram. Here, well-known IP access information, i.e., a well-known IPaddress and a well-known UDP port number can be used as the IP accessinformation of the NRT service signaling channel.

That is, an asynchronous IP stream is transmitted if aProtocol_encapsulation field value in the DST is 0x04 and a device_idvalue indicating the destination address is transmitted through aselector_bytes value if a Selector_type field value is 0x0102. Amultiprotocol_encapsulation_descriptor is used in order to accuratelyanalyze the selector_bytes value and signals the number of valid bytesincluded in the device_id value. As a result, an IP multicast address(or address range) of the NRT service signaling channel transmittedthrough the PID can be determined through the Tap information.

Accordingly, the IP multicast address (or address range) is accessed andan IP stream, i.e., an IP packet, is received and NRT service signalingdata is extracted from the received IP packet.

NRT service data, i.e., NRT content/files, is received based on theextracted NRT service signaling data and the received data can be storedin a storage medium or can be displayed on a display.

In another embodiment of the present invention, the NRT service can besignaled using a new value, for example, 0x96 instead of 0x95 as thestream_type field value of the DST. This embodiment aims to eliminatethe risk that the conventional receiver may malfunction with the NRTservice which is a new application, in the case where the conventionalreceiver operates by determining whether or not a data broadcast streamis present based only on whether or not a stream having a stream typevalue of 0x95 is present. In this case, if a new stream type is defined,it will be possible to allow the conventional receiver to ignore thisstream type, thereby guaranteeing backward compatibility.

FIG. 9 is a flowchart illustrating the process of NRT service signalingdata and the process of extracting the NRT service data.

In an embodiment, as shown in FIG. 9, the service_type field in the VCThas a value of 0x08 as in FIG. 6, indicating that at least one NRTservice is transmitted through the relevant virtual channel.

After a power of a receiver has been turned on, if a default channel ora channel by a user is selected [S1001], the receiver receives a VCT ora PMT [S1002]. And then the receiver determines whether NRT serviceexists or not by parsing the VCT [S1003]. This can be done throughlooking at the service_type in the received virtual channel loop withinthe VCT. The [S1001] step is processed in the tuner and the[S1002]/[S1003] step is processed in the PSI/PSIP section handler.

For instance, if a value of the service_type is not set to ‘0x08’, therelevant virtual channel will not transmit NRT service. The virtualchannel will then transmit conventional service (i.e., legacy ATSCservice), the receiver processes according to the information includedin the virtual channel.

If the service_type field has a value of 0x08, the virtual channel willtransmit NRT service. In such a case, service location descriptor in thevirtual channel of the VCT is parsed to extract the PID of DST [S1004].Then, using the extracted PID, DST is received [S1005]. The [S1004] and[S1005] step is processed through the demultiplexer controlled by theservice manager.

It is then determined whether the corresponding service provided on theselected channel is an NRT service from the received DST [S1006].

The determination of a presence of the NRT service can be performed bychecking the value of the App_id_description field.

For instance, the value of the App_id_description is set to ‘0x0003,’ inthis present invention to identify that the service is an NRTapplication (i.e., NRT service). The value (number) is only an exampleand will not limit the scope of the present invention.

If the value of the App_id_description field is ‘0x0003,’ the value ofthe subsequent Application_id_byte becomes the value of service ID ofthe NRT application (i.e., NRT service). As a result of identifying theNRT application, a Tap is extracted to locate the PID of the MPEG-2 TSpacket separated from the IP datagram of the NRT service signalingchannel [S1007]. And, stream PID including association_tag of the Tap isextracted from the PMT [S1008]. The steps of [S1006] to [S1008] areprocessed by the service manager or the PSI/PSIP section handler.

After receiving and decapsulating the MPEG-2 TS packets corresponding tothe stream PID, i.e., removing the MPEG-2 header, a DSM-CC addressablesection is recovered [S1009]. This process is handled by the addressablesection handler.

Subsequently, after removing section header and CRC checksum from theDSM-CC addressable section, IP datagram transmitting the NRT servicesignaling channel is recovered [S1010], and the NRT service signalingdata is obtained from the recovered IP datagram [S1011]. At this time,the access information of the IP datagram transmitting the NRT servicesignaling channel is received from a well-known destination IP addressand well-known destination UDP port number.

If a value of Protocol_encapsulation in the DST is set to ‘0x04’, anasynchronous IP datagram is transferred. If Selector_type is set to‘0x0102’, a value of device_id indicating a destination address isdelivered via selector_bytes. In order to accurately analyze the valueof the selector_bytes, multiprotocol_encapsulation_descriptor is usedand the number of the valid byte within the device_id is signaled. As aresult, the IP Multicast address (or address range) of the NRT servicesignaling channel transmitted through PID of the Tap information isknown.

Thus, by accessing the IP Multicast address (or address range), IPstream, i.e., IP packet is received, and the NRT service signaling datais extracted from the IP packet.

Based on the extracted NRT service signaling data, NRT service data,i.e., NRT content item/files can be received and stored in a storageunit or can be displayed through a display.

In an embodiment, the NRT service signaling data transmitted through theNRT service signaling channel may include NRT Service Map Table (orService Table: NST) and NRT Information Table (NRT-IT).

In an embodiment, IP datagrams of the NST and NRT-IT has the samewell-known IP address and well-known UDP port number. Therefore, thedetermination of NST and NRT-IT included in the NRT service signalingdata is done through table identifier. Thus, the table identifier can bethe table_id of the corresponding table or the header of the tablesection, and when necessary, table_id_extension can be referred to inorder to identify the table.

The NST provides access information of the NRT service. In oneembodiment NST has a similar table format as the MPEG-2 Private sectiontype.

The NST provides access information of IP based NRT services included inthe virtual channel. For example, the NST provides access information ofeach FLUTE sessions that configures one NRT service.

Here, whether one NST is configured with one session or plurality ofsessions is determined through the table_id field, section_number field,last_section_number field, and the like. And the table may be completedby removing the IP header and the UDP header of the IP datagrams of theNRT service signaling channel and gathering sections having the sametable identifier. For example, by gathering the sections having tableidentifier allocated for NST, the NST is completed.

FIG. 10 and FIG. 11 illustrate a bit stream syntax structure of an NSTsection according to an embodiment of the present invention. The detailof each field of the NST section is explained in the following.

Although the syntax is written in an MPEG-2 private section format forbetter understanding, the data may be in any format. For example, it ispossible to use another method in which the syntax is expressed in aSession Description Protocol (SDP) format and is then signaled through aSession Announcement Protocol (SAP).

In FIG. 10 and FIG. 15, a table_id field includes an 8-bit unsignedinteger number that indicates the type of table section being defined inNRT Service Table (NST).

A section_syntax_indicator field is a 1-bit field that shall be set to‘0’ to always indicate that this table is derived from the “short” formof the MPEG-2 private section table.

A private_indicator field (1-bit) indicates whether the type of thecorresponding section follows the private section type or not. (Thisfield that shall be set to ‘1’)

A section_length is a 12-bit field. It specifies the number of remainingbytes this table section immediately following this field. The value inthis field shall not exceed 4093 (0xFFD)).

A table_id_extension field is a 16-bit field and is table-dependent. Itshall be considered to be logically part of the table_id field providingthe scope for the remaining fields. The table_id_extension fieldincludes NST_protocol_version fields.

The NST_protocol_version field is an 8-bit unsigned integer field whosefunction is to allow, in the future, this NST to carry parameters thatmay be structured differently than those defined in the currentprotocol. At present, the value for the NST_protocol_version shall bezero. Non-zero values of NST_protocol_version may be used by a futureversion of this standard to indicate structurally different tables.

A version_number field (5-bit) indicates the version number of the NST.

A current_next_indicator field is a one-bit indicator, which when se to‘1’ shall indicate that the NST sent is currently applicable. When thebit is set to ‘0’, it shall indicate that the table sent is not yetapplicable and will be the next table to become valid. This standardimposes no requirement that “next” tables (those withcurrent_next_indicator set to ‘0’) must be sent. An update to thecurrently applicable table shall be signaled by incrementing theversion_number field).

A section_number is an 8-bit field that shall give the section number ofthis NST section. The section_number of the first section in an NSTshall be ‘0x00’. The section_number shall be incremented by 1 with eachadditional section in the NST.

A last_section_number is an 8-bit field that shall give the number ofthe last section (i.e., the section with the highest section_number) ofthe NST of which this section is a part).

A num_NRT_services field is an 8-bit field that specifies the number ofservices in this NST section.

A ‘for’ loop, which is also referred to as an “NRT service loop”, isexecuted for the number of times as the number of NRT servicescorresponding to the num_NRT_services field value in providing signalinginformation of a plurality of NRT services. Thus, signaling informationof the corresponding NRT service is indicated for each of the NRTservices included in the NST section. Here, the following fieldinformation may be provided for each NRT service.

An NRT_service_id field is a 16-bit unsigned integer number that shalluniquely identify this NRT service within the scope of this NRT section.The NRT_service_id field of a service shall not change throughout thelife of the service. To avoid confusion, it is recommended that if aservice is terminated, then the NRT_service_id field for the serviceshould not be used for another service until after a suitable intervalof time has elapsed.

An NRT_service_status field is a 2-bit enumerated field that shallidentify the status of this NRT Service. The most significant bit shallindicate whether this NRT Service is active (when set to ‘1’) orinactive (when set to ‘0’) and the least significant bit shall indicatewhether this NRT Service is hidden (when set to ‘1’) or not (when set to‘0’). Hidden services are normally used for proprietary applications,and ordinary receiving devices should ignore them.

A SP_indicator field is a 1-bit field that indicates when set to 1,service protection is applied to at least one of the components neededto provide a meaningful presentation of this NRT Service.

A Short_NRT_service_name_length field (3-bit) instructs the number ofbyte pairs within the Short_NRT_service_name field.

A Short_NRT_service_name filed (16*m bit) indicates a short name of theNRT service. This field may be filled with null data (for example, 0x00)when the NRT service has no short name.

An NRT_service_category field is a 6-bit enumerated type field thatshall identify the type of service carried in the NRT.

A num_components field is a 5-bit field that specifies that number of IPstream components in this NRT Service.

An IP_version_flag is a 1-bit indicator, which when set to ‘0’ shallindicate that source_IP_address, NRT_service_destination_IP_address, andcomponent_destination_IP_address fields are IPv4 addresses. The value of‘1’ for this field is reserved for possible future indication thatsource_IP_address, NRT_service_destination_IP_address, andcomponent_destination_IP_address fields are for IPv6.

A source_IP_address_flag field is a 1-bit Boolean flag that shallindicate, when set, that a source IP address value for this NRT Serviceis present to indicate a source specific multicast.

An NRT_service_destination_IP_address_flag field is a 1-bit Boolean flagthat indicates, when set to ‘1’, that anNRT_service_destination_IP_address field value is present, to serve asthe default IP address for the components of this NRT Service.

A source_IP_address field is a 32 or a 128 bit field that shall bepresent if the source_IP_address_flag field is set to ‘1’ and shall notbe present if the source_IP_address_flag field is set to ‘0’. Ifpresent, this field shall contain the source IP address of all the IPdatagrams carrying the components of this NRT Service. The conditionaluse of the 128 bit-long address version of this field is to facilitatepossible use of IPv6 in the future, although use of IPv6 is notcurrently defined.

An NRT_service_destination_IP_address field is a 32 or a 128 bit fieldthat shall be present if the NRT_service_destination_IP_address_flagfield is set to ‘1’ and shall not be present if theNRT_service_destination_IP_address field is not present, then thecomponent_destination_IP_address field shall be present for eachcomponent in the num_components loop. The conditional use of the 128bit-long address version of this field is to facilitate possible use ofIPv6 in the future, although use of IPv6 is not currently defined.

A ‘for’ loop, which will also be referred to as a “component loop,” isexecuted as much as the number of times as the number of componentscorresponding to the num_components field value to provide accessinformation of a plurality of components. This provides accessinformation of each component included in the NRT service. Here, thefollowing field information may be provided for each component. In anembodiment, one component corresponds to one FLUTE session.

An essential_component_indicator field is a 1-bit indicator which, whenset to ‘1’, shall indicate that this component is an essential componentfor the NRT Service. Otherwise, this field indicates that this componentis an optional component.

A port_num_count field is a 6-bit field that shall indicate the numberof destination UDP ports associated with this UDP/IP stream component.The values of the destination UDP port numbers shall start from thecomponent_destination_UDP_port_num field and shall be incremented byone.

A component_destination_IP_address_flag field is a 1-bit Boolean flagthat shall indicate, when set to ‘1’, that thecomponent_destination_IP_address field is present for this component.

A component_destination_IP_address field (32 or 128 bit) shall bepresent if the component_destination_IP_address_flag field is set to ‘1’and shall not be present if the component_destination_IP_address_flagfield is set to ‘0’. When this field is present, the destination addressof the IP datagrams carrying this component of the NRT Service shallmatch the address in this field. When this field is not present, thedestination address of the IP datagrams carrying this component shallmatch the address in the NRT_service_destination_IP_address field. Theconditional use of the 128 bit-long address version of this field is tofacilitate possible use of IPv6 in the future, although use of IPv6 isnot currently defined.

A component_destination_UDP_port_num field is a 16-bit unsigned integerfield that represents the destination UDP port number for this UDP/IPstream component.

A num_component_level_descriptors field (4-bit) indicates the number ofdescriptors providing the additional information of the component level.

The same number of the component_level_descriptor( ) is included in thecomponent loop providing additional information as the number of thefield value of the num_component_level_descriptors.

A num_NRT_service_level_descriptors field (4-bit) indicates the numberof descriptors that provide additional information about the NRT servicelevel.

The same number of the NRT_service_level_descriptor( ) are included inNRT service loop as the number of the field value ofnum_NRT_service_level_descriptors to provide additional informationabout the NRT service.

A num_virtual_channel_level_descriptors field (4-bit) indicates thenumber of descriptors which provides additional information about thevirtual channel level.

The same number of virtual_channel_level_descriptor( ) included in thevirtual channel loop as the number of the field value of thenum_virtual_channel_level_descriptors to provide additional informationof the virtual channel.

FIG. 12 illustrates an embodiment of a bit stream syntax structure of acomponent_level_descriptors( ). The component_descriptor( ) is used asone of the component level descriptor component_level_descriptors( ) ofthe NST and describes additional signaling information of thecorresponding component.

The following is a description of each field of thecomponent_descriptor( ).

In FIG. 12, a descriptor_tag field (8-bit) is a descriptor identifierand it can be set as an identifier that identifies thecomponent_descriptor( ).

A descriptor_length field (8-bit) describes the remaining length of thedescriptor starting after the descriptor_length field and to the end ofthis descriptor, in bytes.

A component_type field (7-bit) shall identify the encoding format of thecomponent. The value may be any of the values assigned by IANA for thepayload_type of an RTP/AVP stream, or it may be any of the valuesassigned by ATSC, or it may be a “dynamic value” in the range 96-127.For components consisting of media carried via RTP, the value of thisfield shall match the value in the payload_type field in the RTP headerof the IP stream carrying this component. Note that additional values ofthe component_type field in the range of 43-71 can be defined in futureversions of this standard.

A component_encryption_flag (1-bit) informs whether the correspondingcomponent is encrypted or not.

A num_STKM_streams field (8-bit) indicates the number STKM streams ifcomponent_encryption_flag has been encrypted. The num_STKM_streams fieldis an 8-bit unsigned integer field that shall identify the number ofSTKM streams associated with this component.

A STKM_stream_id field (8-bit) is repeated as much as the field value ofNum_STKM_streams and indicates a value that identifies a STKM streamthat can acquire a key required for decryption.

An NRT_component_data (component_type) element provides the encodingparameters and/or other parameters necessary for rendering thiscomponent. The structure of the component_data is determined by thevalue of component_type field.

For example, if the component_type field value is 35 thenNRT_component_data (component_type) field provides component data forH.264/AVC video stream.

In another example, if the component_type field value is 38 thenNRT_component_data (component_type) field provides data for FLUTE filedelivery as shown in FIG. 13.

One NRT service can be included in multiple FLUTE sessions. Thus, oneNRT service may be configured with plurality of FLUTE sessions. EachFLUTE session may be signaled using NRT_component_data( ) as shown inFIG. 13.

FIG. 13 illustrates an example of the bit stream syntax structure ofNRT_component_data( ) that provides data for FLUTE file deliveryaccording to the present invention. The following explains each field inthe NRT_component_data( ).

A TSI field (16-bit unsigned integer) shall be the Transport SessionIdentifier (TSI) of FLUTE session.

A session_start_time field (16-bit) indicates the start time of theFLUTE session. If the field values are all ‘0’, then it can beinterpreted that the FLUTE session has already begun.

A session_end_time field (16-bit) indicates the end time of the FLUTEsession. If the field values are all ‘0,’ then it can be interpretedthat the FLUTE session continues for unlimited amount of time.

A tias_bandwidth_indicator field (1-bit) flags the inclusion of TIASbandwidth information. This bit shall be set to ‘1’ to indicate the TIASbandwidth field is present, and it shall be set to ‘0’ to indicate theTIAS bandwidth field is absent.

An as_bandwidth_indicator field (1-bit) flags the inclusion of ASbandwidth information. This bit shall be set to ‘1’ to indicate the ASbandwidth field is present, and it shall be set to ‘0’ to indicate theAS bandwidth field is absent.

A FEC_OTI_indicator field (1-bit) indicates whether FEC ObjectTransmission Information is provided.

A tias_bandwidth field (16-bit) exists when the as_bandwidth_indicatorfield value is set to ‘1’ and it indicates the maximum bandwidth. Also,it shall be one one-thousandth of the Transport Independent ApplicationSpecific maximum bandwidth as defined in RFC 3890, rounded up to thenext highest integer if necessary. This gives the TIAS bandwidth inkilobits per second.

An as_bandwidth field (16-bit) exists when the as_bandwidth_indicatorfield value is set to ‘1’ and it indicates the maximum AS bandwidth.Also, this value shall be the Application Specific maximum bandwidth asdefined in RFC 4566. This gives the AS bandwidth in kilobits per second.

A FEC_encoding_id field exits when the FEC_OTI_indicator field value isset to ‘1’ and indicates FEC ID used in corresponding FLUTE session.(FEC encoding ID used in this FLUTE session, as defined in RFC 3926).

A FEC_instance_id field exists when the FEC_OTI_indicator field value isset to ‘1’ and indicates FEC instance ID used in the corresponding FLUTEsession. (FEC instance ID used in this FLUTE session, as defined in RFC3926).

The information necessary to receive FLUTE session is provided bysignaling the parameters through the NRT_component_data( ) of thecomponent_descriptor( ) within the component loop.

In other words, according to the time information set by thesession_start_time field and the session_end_time field, thecorresponding FLUTE session is opened and files and the FDT (FileDescription Table) that describes the signaling information of the filesthat configures NRT service (or content) is received. The FDT is used totransmit the list of all the content items, and also providesinformation necessary in acquiring content item and the files includedin the content item.

The FDT includes file id which is the only identifier for identifyingfiles included in the content item and instance id which is the onlyidentifier for identifying the corresponding FDT. Moreover, a contentlinkage which identifies the content item corresponding to the FDT filelevel or instance level, may be allocated.

For example, each file that configures the content item can beidentified through content linkage, TOI, and Content-Location fielddescribed in the FDT of the FLUTE session. In the present invention, thecontent linkage, TOI, and the Content-Location field is referred as thefile identifier.

Also, as described above, the present invention uses service_type fieldof the signaling table (example: VCT) to verify that the NRT service isreceived through the corresponding virtual channel when receiving FixedNRT service in a terrestrial broadcast environment.

For example, in case of Fixed NRT service, as illustrated in FIG. 5 orFIG. 6, if the service type of the VCT is 0x02 (indicating that it isdigital Audio/Video/Data), 0x04 (indicating that it is Data only), or0x08 (indicating that it is NRT Only service), it is determined that theNRT service stream is received through the virtual channel.

However, it is difficult to deal with various use case of NRT with justthe service type fields described above.

Therefore, the present invention transmits signaled service informationincluding the service type (or application type) information and thedetailed information of the service type of the NRT service and controlthe handling of the corresponding NRT service (or content).

In other words, there exists use case of NRT service such as targetedadvertisement, music download, push VOD, and alike, and various storageand playback scenarios according to the various codec combination andthe connected hardware module inside the broadcast receiver according tothe use case. In the present invention, using the service informationincluding service type and detailed information about the service, it isable to efficiently handle the NRT service or the content configuringthe corresponding NRT service. Further, it is possible to use theservice to determine whether it is possible to handle the correspondingNRT service before receiving and storing in storage the NRT service.

For example, a broadcast receiver may determine the method of processingthe corresponding NRT service using the service information. Further,using the service information it is possible to determine how the NRTservice will be provided to the users and also the operation of theassociated application module can be determined.

In the present invention, service information in order to control theNRT service is provided to the broadcast receiver.

The service information may be included as a field or as a descriptor inthe signaling information table.

In an embodiment, in case of Fixed NRT service, the service informationmay be included as a field or as a descriptor in any one of NST orNRT-IT.

In an embodiment, when the service information is included in the NST asa descriptor format, the service information is included as one ofservice level descriptor of the NST. In such as case, the serviceinformation is individually applied in NRT service.

In an embodiment, when the service information is included in the NRT-ITas a descriptor format, the service information is included in theNRT-IT as a content level descriptor. In such a case, the serviceinformation is individually applied to the content (or content item).

For example, assuming that one NRT service is configured in content 1and content 2, if the service information is included in NST, theservice information is applied to content 1 and 2 configuring the NRTservice at the same time. In the other hand, if the service informationis included in the NRT-IT, the service information is applied to eitherone of content 1 and content 2.

In the present invention, for the convenience of explaining thedescriptor describing the service information, it is referred to asNRT_service_info_descriptor( ).

In another embodiment of the present invention, the NRT serviceinformation descriptor may be included in the announcement table of theNRT service. At this point, the NRT service information descriptor mustbe linked with the corresponding NRT service.

FIG. 14 illustrates a bit stream syntax of NRT_service_info_descriptor() according to an embodiment of the present invention.

The detail explanation of each fields of NRT_service_info_descriptor( )are as follows.

The explanation follows a situation where theNRT_service_info_descriptor( ) is included in the service leveldescriptor of the NST.

In FIG. 14, a descriptor_tag field (8-bit) is a descriptor identifierthat can be set to identify NRT_service_info_descriptor( ).

A descriptor_length field (8-bit) indicates the remaining length ofdescriptor from after the descriptor_length field to the end ofdescriptor in byte.

An application_type field (8-bit) indicates a detailed application typeof the corresponding NRT service.

FIG. 15 illustrates an example of the meaning of the application_typefield defined.

For example, if the application_type field value is 0, the correspondingNRT service indicates that it is a video/audio clip. Thus, thevideo/audio clime is a Pull-type and means that download is done throughthe user selecting the NRT service in the guide or channel browsingprocess.

If the application_type field value is 1, it means that thecorresponding NRT service is a service that is updated frequently. Thus,the frequently updated NRT service means that it is a service wherefrequent download and replace is possible without storing the servicefor a long time such as News, Information, and Weather service.

If the application_type field value is 2, then it means that thecorresponding NRT service is a Music Distribution. The MusicDistribution means that it is an audio-only service.

If the application_type field value is 3, then it means that thecorresponding NRT service is a Targeted Advertisement. The TargetedAdvertisement is a play back service triggered by a specific signal or aspecific rule of the inside of the broadcast receiver transmitted by theservice provider after the broadcast receiver has previously received innon-real time and stored in storage media. As an example, the targetedadvertisement cannot be deleted randomly by the broadcast receiver andmay be executed in a file management (delete, update) through thebroadcaster or the service provider.

If the application_type field value is 4, then it means that the NRTservice includes Applications Data. The NRT service using theapplications data means that it a service such as application softwareor executable command set and not A/V content such as a game.

If the application_type field is 5, then it means that the NRT serviceis a Private/Subscription-based Service. The private/subscription-basedservice is a video content of Push-type. Thus, the NRT service using thevideo content is a method where the broadcast receiver automaticallydownloads the corresponding content based on set of rules based on thesubscriber's preference.

If the application_type field value is 6, it means that the NRT serviceincludes Text Data. The NRT service using the text data means that is adocument or a subtitle format service.

If the application_type field value is 7, then it means that thecorresponding NRT service includes File Management Data. The filemanagement data includes command data such as parameter information andfile delete or move of renewing the expiry date of a file or otherfiles.

If the application_type field value is 8, then it means that thecorresponding NRT service is Web content. The web content means that ithas the data configuration for having the same interface as if thewebsite/portal is accessed through the NRT service. The web contentincludes data configured in HTML, JPEG document, and the like.

If the application_type field value is 9, then it means that thecorresponding NRT service is still image. The still image means stillimages such as JPEG, GIF, Bitmap and the like.

If the application_type field value is 10, then it means that the NRTservice is Maintenance data. The Maintenance data includes key valuessuch as software/firmware upgrade, administrative message from theservice provider, subscription information associated with the service,and content protection of the broadcast receiver.

The information included in the application_type field is only anembodiment to explain the present invention, and the present inventionis not limited to the embodiment as the one skilled in the ordinary artcan alter to add or delete the information included.

The user_control_flag field (1-bit) in FIG. 14 indicates whether theuser can randomly execute commands (deletion, move, or update) of a fileor file access when the content provided through the NRT service isstored in the broadcast receiver. In an embodiment, if theuser_control_flag field value is 1, then the service provider has theauthority to control and access the file and the user does not have suchauthority. Targeted advertisement and service provider maintenancemessage can be examples. And in an embodiment, if the user_control_flagfield value is 0, then it means that the user has the authority toaccess and control the corresponding file. In a different embodiment,both the user and the service provider can have authority to access andcontrol the file. In an embodiment to override the field, changing theauthority of the NRT content stored in the storage can be performedthrough the maintenance data.

A storage_requirement field (31-bit) indicates a size of contentprovided through the NRT service in byte.

A num_video_elements field (4-bit) indicates a number of different videocodec types when the content configuring NRT service uses differentvideo codec.

A num_audio_elements field (4-bit) indicates a number of different audiocodec types when the content configuring NRT services uses differentaudio codec.

The ‘for’ loop is executed for the number of video codec assigned to thenum_video_elements field value to provide the correspondingvideo_codec_type and the ‘for’ loop is executed for the number of audiocodec assigned to the num_audio_elements field value to provide thecorresponding audio_codec_type.

An encapsulation_type field (8-bit) indicates encapsulation format usedfor multiplexing audio/video stream. In an embodiment, the formats ofencapsulation may include MPEG-2 system and MPEG-4 system.

A web_content_type field (8-bit) indicates a value to determine thecompatibility of the web browser when the application_type field valueis 8 meaning that it is a web content. As an example, theweb_content_type field may include the existence of flash, XML version,HTML version, and the like. In this case, it is known whether the webcontent (or web document) is written in XML or HTML. For example,according to the web_content_type field if the corresponding web contentis a HTML document and was written in HTML 4.01, then theweb_content_type field indicates that value corresponding to HTML 4.01.In another example, if the web document cannot be viewed in versionsearlier than IE 7.0, the web_content_type field may be used to notify itbeforehand.

Thus, the broadcast receiver can find out what browser is compatiblethrough the web_content_type field. Also, based on web_content_typefield, the broadcast receiver can find out whether the web contentprovided through NRT service is supported by the web browser within thebroadcast receiver.

An expiration_type field (8-bit) indicates the type of expiration periodof the corresponding NRT service when NRT service is stored. Dependingupon the expiration_type field value, the interpretation of theexpiration_value field value, which comes after, is changed.

For example, if the expiration_type field value indicates expirationcontrol by number of playbacks, the expiration_value field valuerepresents the number of playbacks. Thus, the corresponding NRT servicestorage control is executed depending on the number of playbacks.

If the expiration_type field value indicates expiration control by date,the expiration_value field value represents the date and timeinformation. Thus, the corresponding NRT service expiration is managedwhen specific time is specified.

If the expiration_type field does not indicate the expiration controlvalue of the expiration period, then there is no meaning for theexpiration_value field value. In an embodiment, if there is no specificexpiration period to be set, the expiration_value field value is 0. Inanother embodiment, if the expiration_value field value is 0, it can beinterpreted that there is no expiration and the expiration_type field isnot used.

A controlled_rendering_flag field (1-bit) indicates whether thecorresponding data provides display control information when the videois outputted in the NRT service. If the controlled_rendering_flag fieldvalue is 1, then in an embodiment, it indicates that display controlinformation is provided on the corresponding data.

In the present invention, the NRT service may be provided as a fullscreen or as a sub-screen. Here, the Sub-screen means that it is smallerthan a full screen and it can mean Picture In Picture (PIP), Picture OfPicture (POP), double window screen, and the like.

In an embodiment of the present invention, controlled_rendering_flagfield is used to direct whether the corresponding NRT service isprovided in full screen or as a sub-screen.

In an embodiment, if the NRT service is provided in full screen, thecontrolled_rendering_flag field value is set to ‘0,’ and when it isprovided in sub-screen the controlled_rendering_flag field value is setto ‘1.’ In an embodiment of the present invention, if thecontrolled_rendering_flag field value is ‘1,’ and the corresponding NRTservice is played, the control of the video output follows the displaycontrol information provided by the current NRT_service_info_descriptor().

And according to an embodiment, if the controlled_rendering_flag fieldvalue is set to ‘1,’ using the target_window_position_horizontal field,target_window_position_vertical field, target_window_length_horizontalfield, and target_window_length_vertical field, the display controlinformation is provided. Thus when the NRT service is displayed on thescreen, the position and size information is provided.

The target_window_position_horizontal field (16-bit) andtarget_window_position_vertical field (16-bit) indicates the horizontaland vertical coordinates of the video output display of thecorresponding NRT service. For example, thetarget_window_position_horizontal field value andtarget_window_position_vertical field value indicates top left-mostpixel position of the video output.

The target_window_length_horizontal field (16-bit) andtarget_window_length_vertical field (16-bit) indicates the horizontaland vertical size of the window displayed by the video output in pixel.Thus, it indicates the horizontal/vertical size of the sub-screen to bedisplayed by the NRT service.

FIG. 16 illustrates an embodiment of concurrent display function of thebroadcast receiver according to the present invention. According to anembodiment, the sub-screen in the concurrent display is a PIP screen.

As an example, the display may indicate as FIG. 16( a) where both themain screen and the sub-screen display RT service or as indicated byFIG. 16( b), where the main screen displays RT service and thesub-screen displays NRT service. Also, as indicated by FIG. 16( c), themain screen may display NRT service and the sub-screen may display RTservice. Finally, as shown in FIG. 16( d), both the main and sub screenmay display NRT service.

If the corresponding NRT service is displayed in the sub-screen asillustrated by FIG. 16( b) or (d), according to the present inventionthe controlled_rendering_flag field value is set to ‘1,’ andtarget_window_position_horizontal field, target_window_position_verticalfield, target_window_length_horizontal field, andtarget_window_length_vertical field are used to provide the displaycontrol information. Thus, the target_window_position_horizontal field,target_window_position_vertical field, target_window_length_horizontalfield, and target_window_length_vertical field provides the position andthe size of the sub-screen when the NRT service is displayed.

Further, when the corresponding NRT service is displayed in the mainscreen as illustrated by FIG. 16( c) or (d), according to the presentinvention, the controlled_rendering_flag field value is set to ‘0,’ andthe display control information is not provided.

In addition, according to the present invention, input devices such asremote control, menu screen, touch, or the like can be used to switchthe NRT service displayed in a sub-screen to a full screen.

For example, using the main/sub switch key in the remote control, theNRT service displayed in sub-screen can be displayed in full screen.When the main/sub switch key is depressed once more, the NRT servicedisplayed in full screen will get switched back to displaying insub-screen.

In another example, it is possible to display NRT service displayed insub-screen to full screen or from full screen to sub-screen byallocating menu (icon, or button) in a specific location within thedisplayed screen and using a remote control to select the menu.

In another example, it is possible to switch main/sub screen by touchingthe sub-screen.

Therefore, when RT service and NRT service is provided on a same screen,switching main/sub screen using a remote control, menu screen, touch, orthe like is possible.

FIG. 17 illustrates a flowchart of the process handling and acquiringNRT_service_info_descriptor( ) from NST according to the presentinvention.

First of all, NST is extracted using the table identifier from the NRTservice signaling channel. [S1201] And the NRT_service_info_descriptoris extracted from the NRT service loop of the NST as illustrated in FIG.14. [S1202] and the service information of the corresponding NRT serviceare acquired. [S1203] These processes will allow receiving applicationtype and other requirement information in each NRT service unit byexecuting all NRT service described in the NST. For example, if 2 NRTservice is described in the NST, application type and additionalrequirement information can be acquired from the 2 NRT service (NRTservice 1, NRT service 2).

By executing [S1203], the service type of each NRT service is outputtedin the NRT service guide display. For example, if the application_typefield value of the NRT service 1 is 0, it indicates that NRT service 1is ordinary audio/video clip. Also using the other fields ofNRT_service_info_descriptor( ) of NRT service 1, the detail informationof NRT service 1 is indicated. [S1205] For example, capacity, authorityinformation, codec information, encapsulation format information,expiration period of the NRT service 1 may be indicated. Further, whenthe NRT service is displayed on the screen, if thecontrolled_rendering_flag field value is ‘1,’ the NRT service 1 isdisplayed on the sub-screen based on target_window_position_horizontalfield, target_window_position_vertical field,target_window_length_horizontal field, and target_window_length_verticalfield.

If the application type of the NRT service 1 is not currently supportedby the broadcast receiver On Screen Display (OSD) message is outputtedso that the corresponding user can find out.

Also, when the application type is Maintenance Data or TargetedAdvertisement then download can be achieved without user interruption,so it can be omitted when outputting the NRT service guide.

FIGS. 18 and 19 illustrate a bit stream syntax of NRT-IT section thatincludes the detailed information of the content according to thepresent invention.

The bit-stream syntax of the NRT-IT section is described in MPEG-2Private section format for ease of understanding the bit-stream syntaxof the NRT-IT section, but the format of the data can be in otherformats as well. For example, signaling through Session AnnouncementProtocol (SAP) described by Session Description Protocol (SDP) type isalso possible.

The NRT-IT in the NRT service signaling data according to the presentinvention includes information describing the downloadable content itemneeded in order to store the content item in the broadcast receiver. Theinformation provided in the NRT IT includes the title of the content(for example, the name of the program available for download), the timesduring which the content is to be made available for download, andinformation such as content advisories, availability of captionservices, content identification, and other metadata. One item ofcontent may consist of one or more files. For example, an audio/videoclip may come with a JPEG thumbnail image that can be used to representit in on-screen displays. The NRT-IT is used to provide information forvirtual channels of service_type values 0x08.

An instance of the NRT-IT can include data corresponding to anarbitrarily defined time period, or can describe NRT content starting ata specified time and into the indefinite future. Each NRT-IT instanceindicates the start time of the period it covers and the length of theperiod it covers (which may be indefinite). Each NRT-IT instance may besegmented into as many as 256 sections. One section may containinformation for multiple content items, but the information for anygiven content item shall not be segmented and put into two or moresections.

Any content item to be made available for download for a time intervalthat extends beyond the time period covered one or more NRT-IT instancesshall be described only in the first of these NRT-ITs. Content itemdescriptions are placed within the NRT_information_table_section( ) inthe order of their first availability. Therefore, whenlast_section_number is greater than zero (meaning the NRT-IT isdelivered in multiple sections), for sections other than the first(sections for which the value of section_number is greater than zero),all the content item descriptions within a given section shall havefirst availability times that are greater than or equal to all firstavailability times of content item descriptions in the immediatelypreceding section (the section whose value of section_number is onelower than the given section).

Each NRT-IT identifies NRT services associated with the given value ofservice_id available on a particular virtual channel sometime during thetime period it covers.

Here, is possible to find out whether one NRT-IT is made up with onesection or plurality of sections through table_id field, section_numberfield, last_section_number field in the NRT-IT section. Thecorresponding table is completed by gathering sections having same tableidentifier after deleting IP header and UDP header of IP datagram in theNRT service signaling channel. Fort example, by gathering sectionsidentifying the table allocated to NRT-IT, NRT-IT is completed.

The detailed description of the NRT-IT section fields illustrated inFIGS. 18 and 19 are described below.

A Table_id field (8-bit) is set to 0xTBD to identify this table sectionas belonging to the Non-Real-Time Information Table.

A service_id field (16-bit) specifies the service_id field associatedwith the NRT service offering content items described in this section.

An NRT_IT_version_number field (5-bit) indicates the version number ofthis NRT-IT instance, where NRT-IT instance is defined as the set of oneor more NRT_information_table_section( ) having common values forservice_id field, current_next_indicator field, protocol_version field,and time_span_start field. The version number is incremented by 1 modulo32 when any field in the NRT-IT instance changes.

A current_next_indicator (1-bit) field is always set to ‘1’ for NRT-ITsections; the NRT-IT sent is always currently applicable.

A protocol_version field (8-bit) is set to zero. The function ofprotocol_version field is to allow, in the future, this table type tocarry parameters that may be structured differently than those definedin the current protocol. At present, the only valid value forprotocol_version field is zero. Non-zero values of protocol_versionfield may be used by a future version of this standard to indicatestructurally different tables.

A time_span_start field (32-bit) represents the start of the time spancovered by this instance of the NRT-IT, expressed as the number of GPSseconds since 00:00:00 UTC, Jan. 6, 1980. The time of day oftime_span_start field is aligned to minute 00 of the hour. The valuezero for time_span_start field indicates the time period covered by hisNRT-IT instance began in the indefinite past. The value oftime_span_start field is the same for each section of a multi-sectionedNRT-IT instance. The values of time_span_start field andtime_span_length field are set such that the specified time span doesnot overlap with any other NRT-IT instance in this IP subnet.

A time_span_length field (11-bit) indicates the number of minutes,starting at the time indicated by time_span_start field, covered by thisinstance of the NRT-IT. Once established, the value of time_span_lengthfield for a given value of time_span_start field does not change. Avalue of time_span_length field of zero means this NRT-IT instancecovers all time starting at time_span_start field into the indefinitefuture. If the value of time_span_start is zero, time_span_length fieldhas no meaning. The value of time_span_length field is the same for eachsection of a multi-sectioned NRT-IT instance. The values oftime_span_start field and time_span length field are set such that thespecified time span does not overlap with any other NRT-IT instance inthis IP subnet.

A num_items_in_section field (8-bit) indicates the number of contentitems described in this NRT-IT section.

The ‘for’ loop (also referred to as item loop) is executed for number ofcontent items corresponding to the field value of thenum_items_in_section and provides signaling information about pluralityof content items. Thus, the signaling information of the content item ofeach content item included in the NRT service corresponding to theNRT_service_id field value is indicated. The following describes thefield in each content item that may provide the information.

A content_linkage field (32-bit) in the range 0x0001 to 0xFFFF specifiesthe identification number of the content (or content item) described.Value 0x0000 is not used. The content_linkage field performs two linkagefunctions: it links metadata in the NRT-IT to one or more files in theFLUTE FDT associated with this NRT service; it also forms the TF_idfield (identifier for Text Fragment in Text Fragment Table). The valueof the content_linkage field corresponds to either the value of one ofthe FDT-Content-Linkage elements or the value of one of theFile-Content-Linkage elements in the FLUTE FDT for each file associatedwith the content item. The precedence rules may be applied when matchingeach content_linkage value with the corresponding content linkageelements in the FLUTE FDT.

An updates_available field (1-bit) specifies, when set to ‘1,’ that thereferenced content item(s) will be updated. When the updates_availablefield is set to ‘0,’ updates are not expected to be provided for theassociated content item(s), and broadcast receivers are not expected tolook for them.

A TF_available field is Boolean flag, this field specifies, when set to‘1’ that a Text Fragment is present in a Text Fragment Table in theservice signaling channel. When the field is set to ‘0,’ no TextFragment is included in the service signaling channel for this contentitem.

A low_latency field is Boolean flag, this field specifies, when set to‘1,’ that the content is available within the current digital transportwith a low enough latency that its retrieval should be attempted whilethe user waits. When the field is set to ‘0’, retrieval latency islonger and the user interface should suggest to the user to return laterfor viewing.

A playback_length_in_seconds field (20-bit) specifies the duration ofplayback of the content, in seconds. For content consisting only of textand/or still images, the value zero is used. For content that includesaudio or audio/video content, the playback_length_in_seconds fieldindicates the playback length of the audio or audio/video content.

A content_length_included field is Boolean flag, this field indicates,when set to ‘1,’ that the content_length field is present in thisiteration of the “for” loop. Setting this field to ‘0’ indicates thecontent_length field is not present in this iteration of the “for” loop.

A playback_delay_included field is Boolean flag, this field indicates,when set to ‘1,’ that the playback_delay field is present in thisiteration of the “for” loop. Setting this field to ‘0’ indicates theplayback_delay field is not present in this iteration of the “for” loop.

An expiration_included field is Boolean flag, this field indicates, whenset to ‘1,’ that the expiration field is present in this iteration ofthe “for” loop. Setting this field to ‘0’ indicates the expiration fieldis not present in this iteration of the “for” loop.

A duration field (12-bit) in the range 1 to 2880 specifies the expectedcycle time, in minutes, of the carousel containing the referencedcontent item. A broadcast receiver is expected to use the durationparameter to determine the amount of time needed to capture thereferenced content.

A content_length field (40-bit), when present, represents the total sizein bytes of the content item or items. This item is used by thebroadcast receiver to determine if enough memory is available to storeit before downloading is attempted.

A playback_delay field (20-bit) counts of the number of secondsfollowing reception of the first byte of the associated content thebroadcast receiver waits before playback may start, while buffering theincoming stream. A value of zero indicates playback may commenceimmediately. When playback_delay field is not provided, the broadcastreceiver is expected to retrieve the complete file or file set prior toplayback.

An expiration field (32-bit) represents the expiration time of thecontent, expressed as the number of GPS seconds since 00:00:00 UTC, Jan.6, 1980. Following expiration, the content is deleted from memory. If anexpiration time is not specified, broadcast receivers are expected touse methods of their own choosing to manage memory resources.

A content_name_length field (8-bit) specifies the length (in bytes) ofthe content_name_text( ).

A content_name_text( ) field specifies the content item title in theformat of a multiple string structure.

A content_descriptors_length field (12-bit) indicates the total length(in bytes) of the content_descriptor( ) that provide additionalinformation about the content level.

A content_descriptor( )

is separately applied to each content item.

A descriptors_length field (10-bit) indicates the total length (inbytes) of the descriptor ( ).

A descriptor( )

is commonly applied to all content items described in the current NRT-ITsection.

The NRT_service_info_descriptor( ) illustrated in FIG. 14 may beincluded as one of the content_descriptor( ) of NRT-IT illustrated inFIGS. 18 and 19.

If the NRT_service_info_descriptor( ) is included in NRT-IT as adescriptor format, the NRT_service_info_descriptor( ) is separatelyapplied to content (or content item).

For example, if one of NRT service is configured in content 1 andcontent 2, the NRT_service_info_descriptor( ) is applied to either oneof content 1 or content 2. As an example, if theNRT_service_info_descriptor( ) is included in content item loopdescribing content 2, the service information described inNRT_service_info_descriptor( ) is applied to content 2.

The following explains how NRT_service_info_descriptor( ) in FIG. 14 andapplication type information in FIG. 15 is applied in content 2.

An application_type field (8-bit) indicates a detailed application typeof content 2.

For example, if the application_type field value is 0, then content 2indicates that it is a video/audio clip.

If the application_type field value is 1, then it indicates that content2 is frequently updated content.

If the application_type field value is 2, then it indicates that content2 is a Music Distribution.

If the application_type field value is 3, then it indicates that content2 is a Targeted Advertisement.

If the application_type field value is 4, then it indicates that content2 is an Applications Data.

If the application_type field value is 5, then it indicates that content2 is a Private/Subscription-based Content.

If the application_type field value is 6, then it indicates that content2 is a Text Data.

If the application_type field value is 7, then it indicates that content2 is a File Management Data.

If the application_type field value is 8, then it indicates that content2 is Web content.

If the application_type field value is 9, then it indicates that content2 is a still image.

If the application_type field value is 10, then it indicates thatcontent 2 is a Maintenance data.

The user_control_flag field (1-bit) indicates whether file, configuringthe content 2, can be randomly altered by the user for access andcommand (deletion, move, update) when content 2 is stored in thebroadcast receiver.

The storage_requirement field (31-bit) indicates the size of content 2in byte.

The num_video_elements field (4-bit) indicates the number of differentvideo codec types when video codec included in content 2 uses differentvideo codec.

The num_audio_elements field (4-bit) indicates the number of differentaudio codec types when audio codec included in content 2 uses differentaudio codec.

The ‘for’ loop is executed for the number of video codec indicated bythe num_video_elements field value to provide the video_codec_type, andthe ‘for’ loop is executed for the number of audio codec indicated bythe num_audio_elements field value to provide the audio_codec_type.

The encapsulation_type field (8-bit) indicates the encapsulation formatused to multiplex the audio/video stream of content 2.

The web_content_type field (8-bit) indicates the value to determine thecompatibility of the web browser when the application_type field valueis 8, meaning that it is web content.

The expiration_type field (8-bit) indicates the type of the expirationperiod of content 2, when content 2 is stored. Depending on the valuerepresented by the expiration_value field which follows theexpiration_type field value, the interpretation is different.

For example, if the value of Expiration control by number of playbacksis indicated by the expiration_type field value, then theexpiration_value field value indicates the number of playbacks. Thusdepending on the number of playbacks, the storing control for content 2is executed.

If the value of Expiration control by date is indicated by theexpiration_type field value, then the expiration_value field valueindicates the date and time information. Thus, it indicates a specifictime to control the expiration period of content 2.

If there is no value indicated for the Expiration control in theexpiration_type, the expiration_value field value has no meaning.According to an embodiment of the present invention, if there is nospecific expiration date set, the expiration_value field value is 0. Inanother embodiment, it may be interpreted that there is no expiration ifexpiration_value is 0 and the expiration_type field is not used.

A controlled_rendering_flag field (1-bit) indicates whether the displaycontrol information of the corresponding data is provided when video ofcontent 2 is outputted. According to an embodiment, if thecontrolled_rendering_flag field value is ‘1,’ then it indicates that thedisplay control information for the corresponding data is provided.

According to the present invention, content 2 can be provided in a fullscreen or in a sub-screen. Here, the sub-screen means that it is asmaller screen than a full screen and PIP, POP, double window screen areexamples of sub-screen. According to an embodiment of the presentinvention, assuming that NRT service includes content 1 and content 2,content 1 and content 2 are concurrently displayed in one screen.

According to the present invention, whether content 2 is provided infull screen or in sub-screen is determined by thecontrolled_rendering_flag field.

In an embodiment, if content 2 is provided in full screen, thecontrolled_rendering_flag field value is set to ‘0’ and thecontrolled_rendering_flag field value is set to ‘1’ if it is provided insub-screen. According to an embodiment of the present invention, if thecontrolled_rendering_flag field value is ‘1,’ then when playing content2, the control of the video output will follow the information providedby current NRT_service_info_descriptor( ).

In an embodiment, if the controlled_rendering_flag field value is set to‘1,’ then the display control information is provided using thetarget_window_position_horizontal field, target_window_position_verticalfield, target_window_length_horizontal field, andtarget_window_length_vertical field. Thus it provides the location andthe size of the screen when content 2 is displayed.

The target_window_position_horizontal field (16-bit) andtarget_window_position_vertical field (16-bit) indicates the horizontaland vertical coordinates of the display of the video output. Forexample, the target_window_position_horizontal field value andtarget_window_position_vertical field value indicates the position ofthe top left-most pixel of the outputted video.

The target_window_length_horizontal field (16-bit) andtarget_window_length_vertical field (16-bit) indicates the horizontaland vertical size of the window that displays the video output ofcontent 2 in pixel unit. Thus, it indicates the horizontal and verticalsize of the sub-screen to be displayed of content 2 when it is displayedwithin a full screen.

Further, when content 2 is displayed instead of NRT service asillustrated in FIG. 16 (a) through (d) the main and sub screen can beswitched using the methods described above.

FIG. 20 is a block diagram of a broadcast receiver for a Fixed NRTservice according to an embodiment of the present invention.

The broadcast receiver in FIG. 20 includes an Operation Controller 100,a Baseband processor 110, a Service Demultiplexer 120, a Streamcomponent handler 130, a Media Handler 140, a File Handler 150, aService Manager 160, a PVR Manager 170, a first storage unit 180, an SGHandler 190, an EPG Manager 200, an NRT Service Manager 210, anApplication Manager 220, a MiddleWare Engine 230, a Presentation Manager240, and a UI Manager 250.

The Baseband processor 110 includes a Tuner 111 and a Demodulator 112.The Service Demultiplexer 120 includes an MPEG-2 TP Handler 121, aPSI/PSIP Handler 122, a Demultiplexer 123, a Descrambler 124 and asecond storage unit 125.

The Stream component handler 130 includes a Packetized Elementary Stream(PES) decoder 131, an Elementary Stream (ES) decoder 132, a PCR Handler133, an STC Handler 134, a DSM-CC Addressable Section Handler 135, an IPDatagram Handler 136, a Descrambler 137, a UDP Handler 138, a ServiceSignaling Section Handler 138-1, and a Conditional Access System (CAS)139.

The Media Handler 140 includes an A/V Decoders 141. The File Handler 150includes an ALC/LCT Stream Handler 151, a File Reconstruction Buffer152, an XML Parser 153, an FDT Handler 154, a Decompressor 155, a thirdstorage unit 156, and a File Decoder 157.

In the present invention, the first handler which receives and handlesNST and NRT-IT includes at least the Service Manager 160 and the ServiceDemultiplexer 120. Also, the second handler which receives content itemincluding at least one file in non-real time and executes to store in astorage media, includes at least the Baseband processor 110, the ServiceDemultiplexer 120, the Stream component handler 130, and the MediaHandler 140. The storage media can be any one of the first storage unit180, the second storage unit 125, or the third storage unit 156. Thethird handler which receives at least one file of the updated content byaccessing the FLUTE session for transmitting the content includes atleast the Service Manager 160, the NRT Service Manager 210, the StreamComponent Handler 130, and the Media Handler 140.

The Tuner 111 for example in FIG. 20 detects signal transmitted over theterrestrial system with the control from the Service Manager 160 andtunes only the wanted channel, down converts to Intermediate Frequency(IF), and outputs to the Demodulator 112. The Tuner 111 may receive bothreal time stream and non-real time stream. In the present invention,non-real time stream is referred to as NRT stream.

The Demodulator 112 receives digital IF signal of pass bandwidthinputted from the Tuner 111 and performs automatic gain control,reconstructs carrier frequencies and timing to convert into basebandsignal and equalizes the channel. For example, if the broadcast signalis a VSB modulated signal, a VSB demodulation process is executed forautomatic gain control, and reconstructs carrier frequencies and timing.In the Demodulator 112, demodulated and equalized channel data isoutputted to the MPEG-2 TP Handler 121 in a MPEG-2 Transport Stream (TS)packet format.

The MPEG-2 TP Handler 121 is configured of an MPEG-2 TP Buffer and anMPEG-2 TP Parser, temporarily stores the Demodulator 112 output and thenanalyzes TS Header, and outputs to the Demultiplexer 123 if theDemodulator 112 output is a real time A/V TS packet or NRT TS packet andoutputs to the PSI/PSIP Handler 122 if the output is a TS packet forPSI/PSIP table.

The PSI/PSIP Handler 122 is configured of a PSI/PSIP Section Buffer anda PSI/PSIP Parser, and temporarily stores the outputted TS packet fromthe MPEG-2 TP Handler 121 to reconstruct the corresponding table fromPSI/PSIP Section data included in the payload of TS packet withreferencing table identifier and then parse it. At this time, it ispossible to find out whether one table is configured by one section orplurality of sections by the table_id field, section_number field, andlast_section_number field within the corresponding section. Further,completing the corresponding table is possible by gathering sectionshaving identical table identifiers. For example, it is possible tocomplete a VCT by gathering the sections having table identifiersallocated to VCT. Also, each of the parsed table information iscollected by the Service Manager 160 and then stored in the firststorage unit 180. The VCT, PAT, PMT, DST and the like, are stored in thefirst storage unit 180 after going through the process. The ServiceManager 160 stores the table information in the first storage unit 180in the Service Map & Guide DB format.

The Demultiplexer 123 divides audio TS packet and video TS packet andthen outputs to the PES Decoder 131 if the TS packet is real time A/V TSpacket and outputs to the DSM-CC Handler 135 if it is an NRT TS packet.Also, the Demultiplexer 123 outputs to the PCR Handler 133 if the TSpacket includes Program Clock Reference (PCR) and outputs to the CAS 139if the TS packet includes Conditional Access (CA) information. The NRTTS packet is divided into TS packet including NRT service data and TSpacket including NRT service signaling channel. A unique PID isallocated to identify the NRT service in the TS packet of the NRTservice data and the PID of the TS packet including the NRT servicesignaling channel is extracted using DST and PMT.

The Demultiplexer 123 outputs to the Descrambler 124 if the payload ofthe inputted TS packet is scrambled and the Descrambler 124 receivesdescrambling information needed for descrambling (for example, controlword used in scrambling) from the CAS 139 and performs descrambling ofthe TS packet.

The Demultiplexer 123 stores A/V packet of real time from any one of therecord, timed-record, or time shift request in the second storage unit125. The second storage unit 125 is a mass storage device, an example ofit can be a HDD. The download (storage) and upload (playing) in thesecond storage unit 125 is controlled by the PVR Manager 170.

The Demultiplexer 123 outputs to the PES Decoder 131 by dividing audioTS packets and video TS packets from A/V TS packets uploaded from thesecond storage unit 125 according to a playback request.

The Demultiplexer 123, in order to perform such functions, is controlledby Service Manager 160 and/or PVR Manager 170.

Thus the Service Manager 160 receives DST by extracting the PID of theDST from the service location descriptor (or ES loop of PMT) of the VCTwhen the service_type field value indicates that NRT service istransmitted.

Further, NRT service is identified through the received DST, andextracts DST and PMT by using the PID of MPEG-2 TS including NRT servicesignaling channel. The extracted PID is outputted to the Demultiplexer123. The Demultiplexer 123 outputs to the Addressable Section Handler135 the MPEG-2 TS packets corresponding to PID outputted by the ServiceManager 160.

The PCR is a standard time value used in syncing audio ES and video ESin the A/V Decoder 141. The PCR Handler 133 outputs to STC Handler 134reconstructed PCR included in the payload of the inputted TS packet. TheSTC Handler 134 outputs to the A/V Decoder 141 reconstructed System TimeClock (STC) which is the standard clock from the system by the PCR.

The PES Decoder 131 is configured with a PES Buffer and a PES Handler,temporarily stores audio TS packet and video TS packet and removes TSheader from each TS packet and reconstructs to audio PES and video PES.The reconstructed audio PES and video PES is outputted to the ES Decoder132. The ES Decoder 132 is configured with an ES Buffer and an ESHandler, removes each PES header from audio PES and video PES andreconstructs audio ES and video ES which are pure data.

The A/V Decoder 141 uses each decoding algorithms to decode the audio ESand video ES and reconstructs to pre-compressed status and then outputsto the Presentation Manager 240. At this point, depending on the STC,the time sync is executed when audio ES and video ES are decoding. Inone example, the audio decoding algorithm may apply at least one of AC-3decoding algorithm, MPEG 2 audio decoding algorithm, HE AAC decodingalgorithm, AAC SBR decoding algorithm, AAC+ decoding algorithm, HE AACdecoding algorithm, AAC SBR decoding algorithm, MPEG surround decodingalgorithm, or BSAC decoding algorithm, and the video decoding algorithmmay apply at least one of MPEG 2 video decoding algorithm, MPEG 4 videodecoding algorithm, H.264 decoding algorithm, SVC decoding algorithm,and VC-1 decoding algorithm.

The CAS 139 is configured with a CA Stream Buffer and a CA StreamHandler, and the TS packet outputted from the MPEG-2 TP Handler 121 orthe service protection data reconstructed and outputted from the UDPDatagram Handler 138 is temporarily stored and then reconstruct theneeded information (control word used in scrambling) to descramble thestored TS packet or the service protected data. Thus, the CAS 139acquires necessary information to descramble after extracting theEntitlement Management Message (EMM) and Entitlement Control Message(ECM) included in the payload of the TS packet, and then by analyzingthe extracted EMM and ECM. The ECM may include the Control Word (CW)used in scrambling. The CW may be encrypted using the authenticationkey. The EMM may include authentication key of the corresponding dataand the requirements information. The acquired information necessary fordescrambling from the CAS 139 will be outputted to the Descramblers 124,137.

The DSM-CC Section Handler 135 is configured with a DSM-CC SectionBuffer and a DSM-CC Section Parser, temporarily stores the TS packetoutputted from the Demultiplexer 123 and then reconstructs theaddressable section included in the payload of the TS packet, andoutputs to the IP Datagram Handler 136 after removing the header and theCRC checksum from the addressable section and then reconstructing the IPDatagram. The IP Datagram Handler 136 is configured with an IP DatagramBuffer and an IP Datagram Parser, and after buffering the IP datagramdelivered from the DSM-CC Section Handler 135, extracts and analyzes theheader of the buffered IP datagram and then outputs to the UDP DatagramSection Handler 138 after reconstructing the UDP datagram from thepayload of the IP datagram.

At this point, if the IP datagram is scrambled, the scrambled UDPdatagram is descrambled in the Descrambler 137 and then outputted to theUDP Datagram Handler 138. In one example, the Descrambler 137 gathersinformation needed for descrambling (for example, control words neededfor scrambling) from the CAS 139 and descrambles the UDP datagram andthen outputs to the UDP Datagram Handler 138.

The UDP Datagram Handler 138 is configured with UDP Datagram Buffer andUDP Datagram Parser, and after buffering the UDP datagram outputted fromthe IP Datagram Handler 136 or the Descrambler 137, extracts andanalyzes the header of the buffered UDP datagram and reconstructs thedata included in the payload of the UDP datagram. At this point, if thereconstructed data is service protection data then it is outputted tothe CAS 139 and if it is NRT service signaling data, then it isoutputted to the service signaling section handler 138-1, and if it isNRT service data then it is outputted to the ALC/LCT stream handler 151.

In an embodiment, the access information of the IP datagram transmittingNRT service signaling channel is a well-known destination IP address andwell-known destination UDP port number.

Therefore, the IP Datagram Handler 136 and UDP Datagram Handler 138 haswell-known destination IP multicast address and well-known destinationUDP port number, and the IP multicast stream which transmits NRT servicesignaling channel, extracts the NRT service signaling data and outputsto the Service Signaling Section Handler 138-1.

The Service Signaling Section Handler 138-1 is configured with a ServiceSignaling Section Buffer and a Service Signaling Section Parser, andoutputs to the Service Manager 160 the reconstructed and parsed NRT-ITreceived from the NRT Service Signaling Data such as the NST illustratedin FIG. 10 and FIG. 11, and the NRT-IT illustrated in FIG. 18 and FIG.19. The access information of the FLUTE session transmitting contentitems/files configuring NRT service is acquired when the NST is parsed.The detail information of each content item is acquired when the NRT-ITis parsed.

The parsed information from NST and NRT-IT is collected by the ServiceManager 160 and then stored in the first storage unit 180. The ServiceManager 160 stores the extracted information from the NST and the NRT-ITin the first storage unit 180 in the Service Map & Guide format. Inanother embodiment, the NRT Service Manager 210 can perform the taskthat the Service Manager 160 performs. Thus, the parsed information fromthe NST and the NRT-IT may be collected by the NRT Service Manager 210and then stored in the first storage unit 180.

According to an embodiment of the present invention, it is presumed thatNRT_service_info_descriptor( ) is included in the NST and received.

In such a case, the Service Manager 160 or the NRT Service Manager 210extracts NRT_service_info_descriptor from the NRT service loop of theNST as shown in FIG. 14 and acquire service information of thecorresponding NRT service. If the process is performed for all NRTservice included in the NST, service information for each NRT serviceunit, such as application type and additional requirement informationcan be acquired. Also, through the Presentation Manager 240, servicetype for each NRT service is displayed in the guide display. Further,using the other fields of NRT_service_info_descriptor, the detailinformation of the NRT service is indicated. When displaying the NRTservice in a display, if the controlled_rendering_flag field value is‘1,’ then using the target_window_position_horizontal field,target_window_position_vertical field, target_window_length_horizontalfield, and target_window_length_vertical field, the NRT service isdisplayed in a sub-screen. If the application type of the NRT service isnot supported by the current broadcast receiver, an message is outputtedto the user through On Screen Display (OSD).

Further, the corresponding NRT service can be omitted during output whenthe application type is Maintenance Data or Targeted Advertisementbecause download can be achieved without user interruption.

The NRT service manager 210 controls the handling of the correspondingNRT service by the service information acquired from theNRT_service_info_descriptor( ). For example, if the application_typefield value is 3, means that it is a Targeted Advertisement, and thatthe user_control_flag field value is 1. In such a case the user can notrandomly delete the corresponding NRT service. And if the expirationperiod of the expiration_type field value and the expiration_value fieldvalue is limited to 2 playbacks, the NRT service is automaticallydeleted if it was played 2 times.

The ALC/LCT Stream Handler 151 is configured with an ALC/LCT StreamBuffer and an ALC/LCT Stream Parser and after buffering the ALC/LCTstructure data outputted from the UDP Datagram Handler 138, analyzes theheader and the header extension of the ALC/LCT session buffered from thedata. After analyzing the header and the header extension of the ALC/LCTsession, if the data transmitted through ALC/LCT session is in XMLstructure then it is outputted to the XML Parser 153, and if the data isin file structure, it is temporarily stored in the File ReconstructionBuffer 152 and outputted to the File Decoder 157 or stored in the thirdstorage unit 156. If the data transmitted through ALC/LCT session isdata for NRT service, the ALC/LCT stream handler 151 gets controlled bythe NRT service manager 210. If the data transmitted through ALC/LCTsession is compressed, the Decompressor 155 decompresses and outputtedto the XML Parser 153, the File Decoder 157, or the third storage unit156.

The XML Parser 153 analyzes the XML data transmitted through ALC/LCTsession and if the analyzed data is filed-based service then it isoutputted to the FDT Handler 154 and if it is a data for service guide,then it is outputted to the SG Handler 190.

The FDT Handler 154 analyzes and processes the File Description Table ofthe FLUTE protocol through the ALC/LCT session. The FDT Handler 154 iscontrolled by the NRT Service Manager 210 if the received file is forthe NRT service.

The SG Handler 190 gathers and analyzes the data for the service guidetransmitted in XML structure, and then outputs to the EPG Manager 200.

The File Decoder 157 decodes the file outputted from the FileReconstruction Buffer 152, file outputted from the Decompressor 155, orfiled uploaded from the third storage unit 156 using the pre-selectedalgorithm and outputs to the Middleware (M/W) Engine 230 or to the A/VDecoder 141. In an embodiment, the file is a file configuring NRTservice.

The M/W Engine 230 interprets and executes the application, which is thedata of the file structure such as the NRT service. Further, through thePresentation Manager 240, the application may be outputted to an outputdevice such as a screen or a speaker. In an embodiment, the M/W Engine230 is a JAVA platform based M/W Engine.

The EPG Manager 200, depending upon the input from the user, outputs theservice guide data after converting into a display format received fromthe SG Handler 190 to the Presentation Manager 240. The ApplicationManager 220 manages the handling of the application data received in afile format.

The Service Manager 160 gathers and analyzes the NRT service signalingdata transmitted through the PSI/PSIP table data or the NRT servicesignaling channel and creates a service map and the stores in the secondstorage unit 125. The Service Manager 160 controls the accessinformation of the NRT service that the user wants and controls theTuner 111, Demodulator 112, and the IP Datagram Handler 136.

The Operation Controller 100 according to the command from the userthrough the UI Manager 250, controls at least one of the Service Manager160, the PVR Manager 170, the EPG Manager 200, the NRT Service Manager210, the Application Manager 220, and the Presentation Manager 240, andexecutes the user's command.

The NRT Service Manager 210 manages the NRT Service transmitted incontent/file format through the FLUTE session on the IP layer. At thispoint, the files configuring the NRT service is controlled by the NRTService Manager 210 and then stored in either the second storage unit125 or the third storage unit 156.

The UI Manager 250 delivers the user's input through the UI to theOperation Controller 100.

The Presentation Manager 240 provides the user through a speaker and/ora screen at least one of the audio and video data outputted from the A/VDecoder 141, file data (including NRT service data) outputted from theM/W Engine 230, or service guide data outputted from the EPG Manager210.

So far, the explanation was service information applied to Fixed NRTservice.

Mobile NRT Service

From now on, the service information applied to Mobile NRT service isexplained.

In the present invention, the main service data, which is a term usedwith association of Mobile NRT service, is data able to receive from thefixed receiver system, including audio/video (A/V) data. Thus, the mainservice data may include High Definition (HD) or Standard Definition(SD) A/V data and may include various data for data broadcast. Moreover,Known data are data already known from the transmitter/receiverprotocol.

In the present invention, M/H or MH stands for (Mobile/Handheld) whichfollows the first letter of each world and is the opposite concept offixed service. The M/H service data includes at least one of Mobileservice data, handheld service data and for the convenience ofexplanation in the present invention, M/H service data is referred to asMobile service data. The mobile data service includes not only M/Hservice data but also can include services such as mobile or portableservice and therefore the mobile service data is not limited to only M/Hservice data.

The mobile service data can include data such as program executablefile, stock information, or A/V data. Especially, the mobile dataservice may be for mobile or portable device (or broadcast receiver)data service and thus the include A/V data with smaller resolution anddata capacity than the main service data. For example, if the A/V codefor existing main service is MPEG-2 codec, then MPEG-4 Advanced VideoCoding (AVC) or Scalable Video Coding (SVC) can be used for the mobileservice A/V codec because of its better compression efficiency. Further,through the mobile service data, any data may be transmitted. As anexample, Transport Protocol Expert Group (TPEG) data may be transmittedfor real-time traffic information for mobile service data.

Data services using the mobile data service may include weatherinformation, traffic information, stock information,subscriber-participating quiz program, real-time poll, conversationaleducation program, game service, summary of drama, casting information,background music information, location of the drama, results of sportsgames, profile of the athletes, product information and orderingservice, information on program by its time, by its broadcaster, andtopic, and it is not limited to the services described above.

FIG. 21 is illustrates an embodiment of a protocol stack to provideMobile NRT service. In FIG. 21, it shows how IP datagram of mobileservice data and IP datagram of signaling information is transmittedwithout using MPEG-2 TS format by including Adaptation Layer in betweenIP layer and physical layer.

According to FIG. 21, the broadcaster packetized NRT content item/filesthrough the File Transfer Protocol and again packetized according to theAsynchronous Layered Coding/Layered Coding Transport (ALC/LCT). Thepacketized ALC/LCT data is packetized again by UDP method and thepacketized ALC/LCT/UDP data is packetized again by IP method and becomesALC/LCT/UDP/IP data. In the present invention, packetized ALC/LCT/UDP/IPdata is referred to as IP datagram for the convenience of explanation.At this point, OMA BCAST service guide information can also configurethe IP datagram by going through the same process as the NRTcontent/file.

Also the NRT service signaling information is transmitted through NRTservice signaling channel to receive the NRT content item/files, the NRTservice signaling channel is packetized according to the User DatagramProtocol (UDP) method, and the packetized UDP data is again packetizedaccording to the IP method and becomes UDP/IP data. For the convenienceof explanation, UDP/IP data in the present invention is also referred toas IP datagram. The NRT service signaling channel has well-known IPdestination address and well-known destination UDP port number and in anembodiment, it is multicasted by encapsulated in the IP datagram.

Further, A/V streaming for mobile service is configured as one of the IPdatagram through sequentially adding RTP header, UDP header, and IPheader.

In the adaptation layer, IP datagram of the NRT service, NRT servicesignaling channel, and the mobile service data is gathered to generateRS frame. The IP datagram of the OMA BCAST service guide may be includedin the RS frame.

In the RS frame, the column length (number of rows) is set to 187 bytesand the length of the row (number of columns) is N byte and the N can bechanged depending on signaling information such as the transmissionparameter (or TPC data).

An example of the pre-determined transmission method in the mobilephysical layer of the RS frame is modulated in VSB transmission methodand transmitted to receiving system.

Here, the NRT service signaling data transmitted through NRT servicesignaling channel for mobile NRT service includes Service Map Table(SMT). The SMT provides access information of component (or contentitem) included in services, such as RT service or NRT service includedin mobile broadcast.

The SMT is a signaling information table corresponding to NST of theFixed NRT service. If the service included in the mobile broadcast is anNRT service, then the signaling information including the accessinformation of the FLUTE session transmitting the content item/filesconfiguring NRT from the SMT can be extracted. And detailed informationof the content item configuring the NRT service from the OMA BCASTservice guide (SG) can be extracted.

Meanwhile, the following describes the data group structure and RS framestructure used in the mobile broadcast technology data structure.

FIG. 22 illustrates a structure of the data group according to anembodiment of the present invention.

The data configuration according to FIG. 22 are separated into 10 M/Hblock, B1˜B10 in an example. In an embodiment, each M/H block has 16segments in length. According to an embodiment shown in FIG. 22, first 5segment of M/H block B1 and last 5 segment of M/H block B10 areallocated with RS parity data and no allocation for data group A throughD region.

Thus, assuming that one data group is separated into A, B, C, and Dregion, depending on the nature of each M/H block within the data groupeach M/H block can be included in region A through region D. Here, in anembodiment, depending on the interference of the main service data, eachM/H block is included in group A through group D.

The reason the data group is separated into different regions is todifferentiate the use of each regions. Thus, regions with nointerference or less interference by the service data, probably showsstronger receiving capability than regions that have more interference.Also, when the transmitting/receiving side applies system that transmitsdata group inserting the known data, it is possible to insert known dataof the fixed length periodically to the non-interfering region (regionwith no main data mixed) when inserting long known data continuously tothe mobile service data periodically. However, in the region where thereis interference by the main service data, it is hard to insert dataperiodically due to interference by the main data and it is also hard toinsert long known data continuously.

The M/H block B4 through M/H block B7 within the data group shown inFIG. 22 are regions without interference of the main service data andlong known data rows are inserted in the front and the back of each M/Hblock. According to the present invention A region (=B4+B5+B6+B7)includes the M/H block B4 through M/H block B7. In case of region Awhere each M/H block has known data in the front and the back, thereceiving system is able to acquire channel information from the knowndata and perform equalization so region A has the strongest equalizationcapability among regions A through D.

The M/H block B3 and M/H block B8 within data group of FIG. 22 areregions where the interference of the main service data are less andlong known data row is inserted in one side of both M/H blocks. Thus,the known long data row is only inserted at the back of thecorresponding M/H block of M/H block B3 due to less interference of mainservice data and known long data row is only inserted in the front ofthe corresponding M/H block of M/H block B8. In the present invention,the M/H block B3 and M/H block B8 is included in region B (=B3+B8). Incase of region B where only one side of each M/H block having known datarow, the receiving system may acquire channel information from the knowndata and perform equalization, it can have a stronger equalizationcapability than region C/D.

The M/H block B2 and M/H block B9 within the data group as illustratedin FIG. 22 has more main service data interference than region B andcannot insert long known data row in both front and back of both M/Hblocks. In the present invention, the M/H block B2 and M/H block B9 isincluded in region C (=B2+B9).

The M/H block B1 and M/H block B10 within data group shown in FIG. 22has more main service interference than region C and both M/H blockscannot have long known data row inserted in either sides. In the presentinvention, the M/H block B1 and M/H block B10 is included in region D(=B1+B10). The region C/D is very far from the known data row so whenthere is a fast channel change, the receiving capability may not be asgood.

Further, the data group includes signaling information region where thesignaling data (or signaling information) is allocated.

In the present invention, parts of first segment through second segmentof M/H block B4 within the data group can be used as signalinginformation region.

According to an embodiment of the present invention, 276 (=207+69) bytesof M/H block B4 of each data group is used as the signaling informationregion. Thus, the signaling information region is made up with firstsegment 207 bytes of the M/H block B4 and first 69 bytes of the secondsegment. The first segment of the M/H block B4 corresponds to 17th or173rd segment of the VSB field.

The signaling data transmitted through signaling information region canbe distinguished in two types of signaling channel data. One isTransmission Parameter Channel (TPC) data and the other is FastInformation Channel (FIC) data.

The TPC data includes parameters used in the Physical layer module andit is transmitted without interleaving therefore it is possible toaccess by slots in the receiving system.

The FIC data provides fast service acquisition at the receiver andincludes cross layer information between the physical layer and upperlayer. The FIC data is interleaved and transmitted in sub frame unit.

For example, when the data group as illustrated in FIG. 22 includes 6known data rows, the signaling information region is located in betweenthe first known data row and the second known data row. The first knowndata row is inserted at the last 2 segment of the M/H block B3 in thedata group and the second known data row is inserted between the secondand the third segment of the M/H block B3 within the data group. And thethird through the sixth known data row is inserted in each of the last 2segment of M/H block B4, B5, B6, B7. The first and the third through thesixth known data row are separated by 16 segments.

FIG. 23 illustrates a structure of RS frame including Mobile NRT Serviceaccording to an embodiment of the present invention.

The RS frame is converted in time-slicing mode and received in each M/Hframe. One RS frame includes each mobile service data or IP streams ofsignaling data and all RS frame includes IP datagram of Service MapTable (SMT) section. The SMT section data can be in IP stream format orin different format. The RS frame data may include IP datagram such asNRT content/file and OMA BCAST service guide data for NRT service.

In an embodiment, the IP datagram having a well-known IP destinationaddress and well-known UDP port number for transmitting the SMT or theNRT service signaling channel is included in the corresponding RS frameand received.

The RS frame data is transmitted in a plurality of data groups allocatedin the corresponding region.

According to an embodiment of the present invention, RS frame is formedin at least one of M/H Transport Packet (TP). These M/H TP are made ofM/H header and M/H payload.

The M/H payload may include at least one IP datagram of mobile servicedata and NRT service data. The M/H payload may include datagram of SMT.The M/H frame may include IP datagram of OMA BCAST service guide data.

The RS frame in FIG. 22 illustrates allocation of IP Datagram 1 for SMT,IP Datagrams (IP Datagram 2, IP Datagram 3) for two types of NRTservice.

FIG. 24 illustrates a M/H frame structure for transmitting/receivingmobile service data according to an embodiment.

In FIG. 24 one M/H frame is made up with 5 sub-frames and one sub-frameis made up with 16 slots. In this case, one M/H frame has 5 sub-framesand 80 slots.

Further, one slot is made up with 156 data (transport stream packet) atthe packet level and 156 data segments in the symbol level. In otherwords, it has half the size of the VSB field. Thus, one data packethaving 207 bytes has the same data quantity as one data segment,therefore before the data being interleaved; the data packet can be usedas a data segment. Here, two VSB fields are gathered to make up one VSBframe.

One VSB frame includes two VSB field (odd and even field). And each VSBfield includes one field sync segment and 312 data segments.

The slot is the basic time unit for multiplexing mobile service data andmain service data. One slot can include mobile service data or includeonly the main service data.

If the first 118 data packets corresponds to one data group within theslot, the remaining 38 packets becomes main service data packet. Inanother example, if there are no data groups in one slot, thecorresponding slot includes 156 main service data packets.

Meanwhile, mobile service data in one RS frame can be allocated inregions A/B/C/D of the data group and can be allocated in at least oneof regions A/B/C/D. In an embodiment of the present invention, themobile service data in one RS frame is allocated in all of regionsA/B/C/D or allocated in one of regions A/B and regions C/D. In casewhere the mobile service data is allocated in one of regions A/B andregions C/D, the RS frame allocated in regions A/B is different from theRS frame allocated in regions C/D. According to an embodiment of thepresent invention the RS frame allocated in regions A/B of the datagroup is referred to as Primary RS frame and RS frame allocated inregions C/D of the data group is referred to as Secondary RS frame.Moreover, both the primary RS frame and secondary RS frame is includedin one parade. Thus, if the mobile service data in one RS frame isallocated in all regions A/B/C/D of the data group, one parade transmitsone RS frame. In the other hand, if the mobile service data in one RSframe is allocated in regions A/B of the data group and the mobileservice data in the other RS frame is allocated in regions C/D of thedata group, one parade transmits up to two RS frames.

Thus, RS frame mode instructs whether one parade transmits one RS frameor two RS frames. This RS frame mode is transmitted in TPC data.

Table 2 is an example of the RS frame mode.

TABLE 2 RS frame mode Description 00 There is only one primary RS framefor all Group Regions 01 There are two separate RS frames Primary RSframe for Group Regions A and B Secondary RS frame for Group Regions Cand D 10 Reserved 11 Reserved

In Table 2, to indicate the RS frame mode, 2 bit is allocated. As shownin Table 2, if the RS frame mode value is 00 then one parade transmitsone RS frame and if the RS frame mode value is 01, one parade transmitstwo RS frames (primary RS frame and secondary RS frame). Thus, if the RSframe mode value is 01, the data of the Primary RS frame for region A/Bis transmitted by being allocated in region A/B of the data group, anddata of the Secondary RS frame for region C/D is transmitted by beingallocated in region C/D of the data group.

In an embodiment, as same as the allocation with the data group, theparades are allocated far away from each other as possible. This is toeffectively deal with bust error generating within one sub-frame.

The allocation method of the parades can be differently applied to eachM/H frame and also can be applied equally to all M/H frame. Further, theallocation method can be applied equally to all the sub-frame in one M/Hframe or can be applied differently for each sub-frame. According to anembodiment of the present invention, the method can be applieddifferently for each M/H frame and the method can be equally applied toall sub-frames in one M/H frame. Thus, the structure of the M/H framecan be different by each M/H frame unit and this allows the ensembledata ratio to be flexibly adjusted.

Thus, in an embodiment the concept of Ensemble is introduced and definesthe set of the service. One M/H ensemble has the same QoS and is codedin same FEC code. Also, one ensemble has same ensemble id andcorresponds to continuous RS frame.

FIG. 25 illustrates a structure of data transmission in the physicallayer where FIC data is included in each data group according to anembodiment of the present invention.

As explained, M/H frame of about 0.968 seconds is partitioned into 5sub-frames and each sub-frame exists with many data groups correspondingto ensemble and each ensemble includes data groups with one ensembleinterleaved in M/H frame unit to make up one RS frame. In FIG. 24 thereare 2 ensembles (NoG=4 and NoG=3). Further fixed part (e.g. 37bytes/data group) of each data group is used to deliver FIC data appliedapart from the RS frame data channel. FIC region allocated to each datagroup includes one FIC segment and the FIC segments are interleaved insub-frame unit. For example, in an embodiment, RS encoding and serialconcatenated convolution code (SCCC) encoding is applied to the RS framedata and RS encoding and parallel concatenated convolution code (PCCC)encoding is applied to the FIC data. Meanwhile, RS encoding and PCCCencoding is applied to TPC data as well. Here, the (187+P, 187)-RSencoding is applied to the RS frame data and (51, 37)-RS encoding isapplied to the FIC data. In an embodiment, (18, 10)-RS encoding isapplied to the TPC data. P indicates the number of parity bytes.

FIG. 26 illustrates a bit stream syntax of SMT section providingsignaling information of NRT service data transmitted in with the RSframe of FIG. 23 according to an embodiment.

Here, the corresponding syntax is described in MPEG-2 Private sectionformat for ease of explanation, but the data format can be in any typeof format.

The SMT describes the mobile service signaling information (or NRTservice signaling information) and IP access information within thetransmitted Ensemble. The SMT also provides broadcast stream informationof the corresponding service by using the Transport Stream ID which isthe identifier of Broadcast stream of each service. Further, accordingto an embodiment of the present invention, SMT includes Descriptioninformation of each mobile service (or NRT service) in one ensemble andalso can include addition information about the Descriptor region.

As illustrated in FIG. 26, SMT section can be transmitted in IP streamformat within the RS frame. Here, the RS frame decoders of the receiver,which will be explained, decodes the inputted RS frame and outputs thedecoded RS frame to the corresponding RS frame handler. Further, each RSframe handler is distinguished in row unit of the inputted RS frame andmakes up the M/H TP and outputted to M/H TP handler.

The examples of the fields that can be transmitted through SMT are asfollows.

A table_id field is an 8-bit unsigned integer number that indicates thetype of table section being defined in Service Map Table (SMT).

A section_syntax_indicator is a 1-bit field that shall be set to ‘0’ toalways indicate that this table is derived from the “short” form of theMPEG-2 private section table.

A private_indicator field is a 1-bit field that shall be set to ‘1,’ toindicate whether the SMT follows the private section.

A section_length field is a 12-bit field. It specifies the number ofremaining bytes of the table section immediately following this field.The value in this field shall not exceed 4093 (0xFFD).

A table_id_extension field is a 16-bit field and is table-dependent. Itshall be considered to be logically part of the table_id field providingthe scope for the remaining fields. Here, the table_id_extension fieldincludes the SMT_protocol_version.

A SMT_protocol_version field is an 8-bit unsigned integer field whosefunction is to allow, in the future, that current SMT to carryparameters that may be structured differently than those defined in thecurrent protocol. At present, the value for the SMT_protocol_versionshall be zero. Non-zero values of SMT_protocol_version may be used by afuture version of this standard to indicate structurally differenttables.

An ensemble_id field is an 8-bit unsigned integer field in the range0x00 to 0x3F that shall be the Ensemble ID associated with thisEnsemble. The value of this field shall be derived from the parade_idcarried from the baseband processor of physical layer subsystem, byusing the parade_id of the associated Parade for the least significant 7bits, and using ‘0’ for the most significant bit when the Ensemble iscarried over the Primary RS frames, and using ‘1’ for the mostsignificant bit when the Ensemble is carried over the Secondary RSframes.

A version_number field (5-bit) indicates the SMT version number.

A current_next_indicator field (1-bit) when set to ‘1’ shall indicatethat the Service Map Table sent is currently applicable. When the bit isset to ‘0,’ it shall indicate that the table sent is not yet applicableand will be the next table to become valid. This standard imposes norequirement that “next” tables (those with current_next_indicator set to‘0’) must be sent. An update to the currently applicable table shall besignaled by incrementing the version_number field.

A section_number field (8-bit) shall give the section number of this NRTService Signaling Table section. The section_number of the first sectionin an NRT Service Signaling Table shall be 0x00. The section_numbershall be incremented by 1 with each additional section in the NRTService Signaling Table.

A last_section_number field (8-bit) shall give the number of the lastsection (i.e., the section with the highest section_number) of theService Signaling table of which this section is a part.

A num_services field (8-bit) specifies the number of services in thisSMT section. The Ensemble including the SMT can have at least one mobileservice included and received, can have at least one NRT serviceincluded and received, or can have both mobile service and NRT serviceincluded and received. If the SMT includes ensemble only including NRTservices, the number of NRT services included in the SMT can beinstructed.

The signaling information of a plurality of services is provided forexecuting the ‘for’ loop (or also referred to as service loop) for thenumber of services corresponding to the num_services field value. Thus,the signaling information of the corresponding services included in theSMT section is indicated. Here, the service can be a mobile service oran NRT service. The information of the field regarding each service isexplained as follows.

A service_id field is a 16-bit unsigned integer number field that shalluniquely identify this service within the scope of this SMT section. Theservice_id of a service shall not change throughout the life of theservice. To avoid confusion, it is recommended that if a service isterminated, then the service_id for the service should not be used foranother service until after a suitable interval of time that haselapsed. Here, if the service is an NRT service, then the service_ididentifies the NRT service.

A multi_ensemble_service field is a 2-bit enumerated field that shallidentify whether the Service is carried across more than one Ensemble.Also, this field shall identify whether or not the Service can berendered only with the portion of Service carried through this Ensemble.

A service_status field (2-bit) identifies the status of thecorresponding service. Here, MSB instructs whether the service is active(‘1’) or inactive (‘0’) and LSB instructs whether the service is hidden(‘1’) or not (‘0’). If the service is an NRT service, the MSB of theservice_status field instructs whether the NRT service is active (‘1’)or inactive (‘0’) and LSB instructs whether the NRT service is hidden(‘1’) or not (‘0’).

A SP_indicator field is a 1-bit field that indicates when se to 1, thatthe service protection is applied to at least one of the componentsneeded to provide a meaningful presentation of this Service.

A short_service_name_length field (3-bit) indicates the length of theshort service name described in short_service_name field in bytes.

A short_service_name field indicates the short name of the correspondingservice. In the short name of the Service, each character shall beencoded per UTF-8 [20]. When there are an odd number of bytes in theshort name, the second byte of the last of the byte pair per the paircount indicated by the short_service_name_length field shall contain0x00. For example, if the service is a mobile service it indicates theshort name of the mobile service, and if the service is an NRT service,it indicates the short name of the NRT service.

A service_category field (6-bit) as illustrated in Table 3, identifiesthe type of the service. If the field value indicates “Informative only”the value of the field is set to informative description of thecorresponding category. And the receiver is requested to examine thecomponent_level_descriptors( ) field of the SMT to identify the actualservice of the category. For services including video and/or audiocomponents, it will have NTP time base component.

TABLE 3 service_category Meaning 0x00 The service category is notspecified by the service_category field. Look in thecomponent_level_descriptors( ) to identify the category of service. 0x01Basic TV (Informative only)—Look in the component_level_descriptors( )to identify the specific category of service. 0x02 Basic Radio(Informative only)—Look in the component_level_descriptors( ) toidentify the specific category of service. 0x03 RI service—Rights Issuerservice as defined in Part #6 [34] of this standard. 0x04-0x07 Notspecified by the current version of this standard. 0x08 ServiceGuide—Service Guide (Announcement) as defined in Part #4 [x] of thisstandard. 0x09-0x0C Not specified by the current version of thisstandard. 0x0E NRT Service 0x0F-0XFF [Reserved for future ATSC use]

Especially, with regard to the present invention, as an example of theservice_category field value, if the value indicates ‘0x0E’ then itmeans that the corresponding service is an NRT service. Here, thesignaling information describing the service in the SMT sectioncorresponds to an NRT service signaling information.

A num_components field (5-bit) specifies the number of IP streamcomponents in this service.

IP_version_flag field (1-bit) is an indicator, which when set to ‘0’shall indicate that source_IP_address, service_destination_IP_address,and component_destination_IP_address fields are IPv4 addresses. Thevalue of ‘1’ for this field is reserved for possible future indicationthat source_IP_address, service_destination_IP_address, andcomponent_destination_IP_address fields are for IPv6. Use of IPv6addressing is not currently defined.

A source_IP_address_flag field (1-bit) is a Boolean flag that shallindicate, when set, that a source IP address value for this Service ispresent to indicate a source specific multicast.

A service_destination_IP_address_flag field (1-bit) is a Boolean flagthat indicates, when set to ‘1,’ that a service_destination_IP_addressvalue is present, to serve as the default IP address for the componentsof this Service.

A source_IP_address field (32 or 128 bit) shall be present if thesource_IP_address_flag is set to ‘1’ and shall not be present if thesource_IP_address_flag is set to ‘0.’ If present, this field shallcontain the source IP address of all the IP datagrams carrying thecomponents of this Service. The conditional use of the 128 bit-longaddress version of this field is to facilitate possible use of IPv6 inthe future, although use of IPv6 is not currently defined.

If the service is an NRT service, the Source_IP_address field becomesthe source IP address of same server transmitting all channels of FLUTEsession.

A service_destination_IP_address field (32 or 128 bit) shall be presentif the service_destination_IP_address_flag is set to ‘1’ and shall notbe present if the service_destination_IP_address_flag is set to ‘0.’ Ifthis service_destination_IP_address is not present, then thecomponent_destination_IP_address field shall be present for eachcomponent in the num_components loop. The conditional use of the 128bit-long address version of this field is to facilitate possible use ofIPv6 in the future, although use of IPv6 is not currently defined. Ifthe service is an NRT service, the service_destination_IP_address fieldis signaled if destination IP address of session level of FLUTE sessionis present.

Meanwhile, according to an embodiment, SMT provides information aboutplural components using the ‘for’ loop.

The access information of the plural components is provided by executing‘for’ loop (or referred to as component loop) for the number ofcomponents corresponding to the num_components field value.

An essential_component_indicator field (1-bit) when set to ‘1,’ shallindicate that this component is an essential component for the service.Otherwise, this field indicates that this component is an optionalcomponent.

A component_destination_IP_address_flag field (1-bit) is a Boolean flagthat shall indicate, when set to ‘1,’ that thecomponent_destination_IP_address is present for this component.

A port_num_count field (6-bit) shall indicate the number of destinationUDP ports associated with this UDP/IP stream component. The values ofthe destination UDP port numbers shall start from thecomponent_destination_UDP_port_num field and shall be incremented byone, except in the case of RTP streams, when the destination UDP portnumbers shall start from the component_destination_UDP_port_num fieldand shall be incremented by two, to allow for the RTCP streamsassociated with the RTP streams.

A component_destination_UDP_port_num field (16-bit) that represents thedestination UDP port number for this UDP/IP stream component. For RTPstreams, the value of component_destination_UDP_port_num shall be even,and the next higher value shall represent the destination UDP portnumber of the associated RTCP stream.

A component_destination_IP_address field (32 or 128 bit) shall bepresent if the component_destination_IP_address_flag is set to ‘1’ andshall not be present if the component_destination_IP_address_flag is setto ‘0.’ When this field is present, the destination address of the IPdatagrams carrying this component of the M/H Service shall match theaddress in this field. When this field is not present, the destinationaddress of the IP datagrams carrying this component shall match theaddress in the service_destination_IP_address field. The conditional useof the 128 bit-long address version of this field is to facilitatepossible use of IPv6 in the future, although use of IPv6 is notcurrently defined.

A num_component_level_descriptors field (4-bit) indicates the number ofdescriptors providing additional information of the component level.

The component_level_descriptor( ) is included in the component loop fornumber corresponding to the num_component_level_descriptors field valueand provides additional information about the component.

A num_service_level_descriptors field (4-bit) indicates the number ofdescriptors providing the additional information of the service level.

The service_level_descriptor( ) is included in the service loop for thenumber corresponding to the num_service_level_descriptors field valueand provides additional information about the service. If the service isa mobile service, additional information about the mobile service isprovided and if the service is an NRT service, additional informationabout the NRT service is provided.

A num_ensemble_level_descriptors field (4-bit) indicates the number ofdescriptors providing the additional information of the ensemble level.

The ensemble_level_descriptor( ) is included in the ensemble loop forthe number corresponding to the num_ensemble_level_descriptors fieldvalue and provides additional information about the ensemble.

Meanwhile, the SMT illustrated in FIG. 26 may providecomponent_level_descriptors( ) which corresponds to the samecomponent_descriptors( ) provided in FIG. 12.

The component_descriptor( ) is used as one ofcomponent_level_descriptors( ) of SMT and describes additional signalinginformation of the corresponding component.

Therefore, it is possible to use the component_descriptor( ) in FIG. 12to provide the signaling information needed to receive the FLUTE sessionin mobile NRT service.

For example, if the component_type field value of component_descriptor() is 38 as illustrated in FIG. 12, component_data(component_type) fieldprovides data for FLUTE file delivery as illustrated in FIG. 13. Theexplanation of each field in FIG. 12 and FIG. 13 have been explained andtherefore is omitted.

Meanwhile, when receiving Mobile NRT service in a mobile broadcastingenvironment as mentioned in the present invention, whether NRT serviceis received through corresponding RS frame or not is checked by usingservice_category field of the signaling table (for example, SMT).

For example, in Mobile NRT service, as described in Table 3, if theservice category field value of the SMT service is 0x0E (meaning NRTservice), then it is deemed that NRT service is received through the RSframe.

However, it is hard to handle various NRT use case by just using theservice category field.

Therefore, the present invention is able to control the operation of NRTservice (or content) according to the service information in thebroadcast receiver by transmitting the signaled service informationincluding the service type (or application type) and the detailedinformation of the service type information of mobile NRT service. Inother words, in the present invention, using the service informationincluding the service type and the detailed information of the servicetype, it is possible to effectively handle the NRT service or thecontents included in the NRT service. Further, using the serviceinformation to check whether the NRT service can be handled beforereceiving NRT service and storing in a storage medium is also possible.

For example, the broadcast receiver may determine the handling method ofthe NRT service by using the service information. Also, using theservice information, it is possible to determine how to provide the userwith the NRT service and it is possible to determine the operation ofthe associated application module.

The service information can be included in the SMT as a field type or adescriptor type.

In an embodiment, if the service information is included as a descriptorformat in the SMT, the service information is included as one of theservice level descriptor of the SMT. In such a case, the serviceinformation is applied separately in NRT service.

For example, if one NRT service includes content 1 and content 2, theservice information is applied to content 1 and content 2 included inthe NRT service at the same time.

In an embodiment, for mobile NRT service, theNRT_service_info_descriptor( ) shown in FIG. 14 is applied.

In an embodiment, the meanings in FIG. 15 applies to theapplication_type field value in NRT_service_info_descriptor( ).

Therefore, explanation of each field of NRT_service_info_descriptor( )included in SMT for mobile NRT service is explained in FIG. 14 and FIG.15, so it is omitted in this part.

SMT is extracted by using the table identifier from the NRT servicesignaling channel, NRT_service_info_descriptor, as illustrated in FIG.14, is extracted from the SMT service loop, and acquire serviceinformation of the NRT service. The extracted service information isdisplayed in the NRT service guide display. For example, if the NRTservice application_type field value is 0, then the NRT service is anordinary audio/video clip. Also, detailed information of the NRT serviceis indicated by using other fields of NRT_service_info_descriptor( ) ofthe NRT service. For example, capacity, authority information, codecinformation, encapsulation format information, expiration period, andthe like of the NRT service may be indicated. When the NRT service isdisplayed in the display, if the controlled_rendering_flag field valueis ‘1,’ the NRT service is displayed in the sub-screen based ontarget_window_position_horizontal field, target_window_position_verticalfield, target_window_length_horizontal field, andtarget_window_length_vertical field.

If the NRT service application_type is not supported by the currentbroadcast receiver, message of On Screen Display (OSD) is displayed sothat the user knows about it.

Further, if the application type is Maintenance Data or TargetedAdvertisement, the download is performed without user intervention so itis omitted when displaying the NRT service guide.

As described, the NRT_service_info_descriptor( ) in FIG. 14 is includedin the service level descriptor of NST or in the content leveldescriptor of NRT-IT for Fixed NRT service. Also, it is included in theservice level descriptor of SMT for Mobile NRT service.

FIG. 27 illustrates a block diagram of a receiving system for receiving,storing and playing NRT content for NRT service. The solid arrow line inFIG. 27 indicates the Data path and the dotted arrow line indicates theControl signal path.

The receiving system according to the present invention may include anoperation controller 2100, a tuner 2111, a demodulator 2112, anequalizer 2113, a known sequence detector (or known data detector) 2114,a block decoder 2115, a primary Reed-Solomon (RS) frame decoder 2116, asecondary RS frame decoder 2117, a signaling decoder 2118, and abaseband controller 2119. The receiving system according to the presentinvention may further include an FTC handler 2121, a service manager2122, a service signaling handler 2123, and a first storage unit 2124.The receiving system according to the present invention may furtherinclude a primary RS frame buffer 2131, a secondary RS frame buffer2132, and a transport packet (TS) handler 2133. The receiving systemaccording to the present invention may further include an InternetProtocol (IP) datagram handler 2141, a descrambler 2142, an UserDatagram Protocol (UDP) datagram handler 2143, a Real-time TransportProtocol/Real-time Transport Control Protocol (RTP/RTCP) datagramhandler 2144, a Network Time Protocol (NTP) datagram handler 2145, aservice protection stream handler 2146, a second storage unit 2147, anAsynchronous Layered Coding/Layered Coding Transport (ALC/LCT) streamhandler 2148, an Extensible Mark-up Language (XML) parser 2150, and aField Device Tool (FDT) handler 2151. The receiving system according tothe present invention may further include an Audio/Video (A/V) decoder2161, a file decoder 2162, a third storage unit 2163, a middle ware(M/W) engine 2164, and a Service Guide (SG) handler 2165. The receivingsystem according to the present invention may further include anElectronic Program Guide (EPG) manager 2171, an application manager2172, and a User Interface (UI) manager 2173.

Herein, for simplicity of the description of the present invention, thetuner 2111, the demodulator 2112, the equalizer 2113, the known sequencedetector (or known data detector) 2114, the block decoder 2115, theprimary RS frame decoder 2116, the secondary RS frame decoder 2117, thesignaling decoder 2118, and the baseband controller 2119 will becollectively referred to as a baseband processor 2110. The FIC handler2121, the service manager 2122, the service signaling handler 2123, andthe first storage unit 2124 will be collectively referred to as aservice multiplexer 2120. The primary RS frame buffer 2131, thesecondary RS frame buffer 2132, and the TS handler 2133 will becollectively referred to as an IP adaptation module 2130. The IPdatagram handler 2141, the descrambler 2142, the UDP datagram handler2143, the RTP/RTCP datagram handler 2144, the NTP datagram handler 2145,the service protection stream handler 2146, the second storage unit2147, the ALC/LCT stream handler 2148, the XML parser 2150, and the FDThandler 2151 will be collectively referred to as a common IP module2140. The A/V decoder 2161, the file decoder 2162, the third storageunit 2163, the M/W engine 2164, and the SG handler 2165 will becollectively referred to as an application module 2160.

In addition, although the terms used in FIG. 27 are selected fromgenerally known and used terms, some of the terms mentioned in thedescription of FIG. 27 have been selected by the applicant at his or herdiscretion, the detailed meanings of which are described in relevantparts of the description herein. Furthermore, it is required that thepresent invention is understood, not simply by the actual terms used butby the meaning of each term lying within.

Referring to FIG. 27, the baseband controller 2119 controls theoperation of each block included in the baseband processor 2110.

By tuning the receiving system to a specific physical channel frequency(or physical transmission channel frequency, PTC), the tuner 2111enables the receiving system to receive main service data, whichcorrespond to broadcast signals for fixed-type broadcast receivingsystems, and mobile service data, which correspond to broadcast signalsfor mobile broadcast receiving systems. At this point, the tunedfrequency of the specific physical channel is down-converted to anintermediate frequency (IF) signal, thereby being outputted to thedemodulator 2112 and the known sequence detector 2114. Morespecifically, the tuner 2111 may receive main service data and mobileservice data which are real-time service data, and receive non-real timeservice data.

The demodulator 2112 performs self-gain control, carrier recovery, andtiming recovery processes on the passband digital IF signal inputtedfrom the tuner 2111, thereby modifying the IF signal to a basebandsignal. Then, the demodulator 2112 outputs the baseband signal to theequalizer 2113 and the known sequence detector 2114. The demodulator2112 uses the known data symbol sequence inputted from the knownsequence detector 2114 during the timing and/or carrier recovery,thereby enhancing the demodulating performance. The equalizer 2113compensates channel-associated distortion included in the signaldemodulated by the demodulator 2112. Then, the equalizer 2113 outputsthe distortion-compensated signal to the block decoder 2115. By using aknown data symbol sequence inputted from the known sequence detector2114, the equalizer 2113 may enhance the equalizing performance.Furthermore, the equalizer 2113 may receive feed-back on the decodingresult from the block decoder 2115, thereby enhancing the equalizingperformance.

The known sequence detector 2114 detects known data place (or position)inserted by the transmitting system from the input/output data (i.e.,data prior to being demodulated or data being processed with partialdemodulation). Then, the known sequence detector 2114 outputs thedetected known data position information and known data sequencegenerated from the detected position information to the demodulator2112, the equalizer 2113, and the baseband controller 2119.Additionally, in order to allow the block decoder 2115 to identify themobile service data that have been processed with additional encoding bythe transmitting system and the main service data that have not beenprocessed with any additional encoding, the known sequence detector 2114outputs such corresponding information to the block decoder 2115.

If the data channel-equalized by the equalizer 2113 and inputted to theblock decoder 2115 correspond to data processed with both block-encodingof serial concatenated convolution code (SCCC) method andtrellis-encoding by the transmitting system (i.e., data within the RSframe, signaling data), the block decoder 2115 may performtrellis-decoding and block-decoding as inverse processes of thetransmitting system. On the other hand, if the data channel—equalized bythe equalizer 2113 and inputted to the block decoder 2115 correspond todata processed only with trellis-encoding and not block-encoding by thetransmitting system (i.e., main service data), the block decoder 2115may perform only trellis-decoding.

The signaling decoder 2118 decodes signaling data that have beenchannel-equalized and inputted from the equalizer 2113. It is assumedthat the signaling data (or signaling information) inputted to thesignaling decoder 2118 correspond to data processed with bothblock-encoding and trellis-encoding by the transmitting system. Examplesof such signaling data may include transmission parameter channel (TPC)data and fast information channel (FIC) data.

For example, among the data that are being inputted, the signalingdecoder 2118 performs regressive turbo decoding of a parallelconcatenated convolution code (PCCC) method on data corresponding to thesignaling information region. Subsequently, the signaling decoder 2118separates FIC data and TPC data from the regressive-turbo-decodedsignaling data. Additionally, the signaling decoder 2118 performsRS-decoding as inverse processes of the transmitting system on theseparated TPC data, thereby outputting the processed data to thebaseband controller 2119. Also, the signaling decoder 2118 performsdeinterleaving in sub-frame units on the separated FIC data, so as toperform RS-decoding as inverse processes of the transmitting system onthe deinterleaved FIC data, thereby outputting the processed data to theFIC handler 2121. The FIC data being deinterleaved and RS-decoded fromthe signaling decoder 2118 and outputted to the FIC handler 2121 aretransmitted in units of FIC segments.

The FIC handler 2121 receives FIC data from the signaling decoder 2118,so as to extract signaling information for service acquisition (i.e.,mapping information between an ensemble and a mobile service). In orderto do so, the FIC handler 2121 may include an FIC segment buffer, an FICsegment parser, and an FIC chunk parser.

The FIC segment buffer buffers FIC segment groups being inputted in M/Hframe units from the signaling decoder 2118, thereby outputting thebuffered FIC segment groups to the FIC segment parser. Thereafter, theFIC segment parser extracts the header of each FIC segment stored in theFIC segment buffer so as to analyze the extracted headers. Then, basedupon the analyzed result, the FIC segment parser outputs the payload ofthe respective FIC segments to the FIC chunk parser. The FIC chunkparser uses the analyzed result outputted from the FIC segment parser soas to recover the FIC chunk data structure from the FIC segmentpayloads, thereby analyzing the received FIC chunk data structure.Subsequently, the FIC chunk parser extracts the signaling informationfor service acquisition. The signaling information acquired from the FICchunk parser is outputted to the service manager 2122.

Meanwhile, the service signaling handler 2123 includes a servicesignaling buffer and a service signaling parser. The service signalinghandler 2123 buffers table sections (for example, SMT sections) of aservice signaling channel received from the UDP datagram handler 2143and analyzes and processes the buffered table sections. The SMTinformation processed by the service signaling handler 2123 is alsooutput to the service manager 2122.

In an embodiment, the SMT section or a service signaling channel thatcarries the SMT section is received within a corresponding RS frame in aformat of a UDP/IP packet that has a well-known IP destination addressand a well-known destination UDP port number. Accordingly, the receptionsystem can parse each SMT section and descriptors of each SMT sectionwithout requiring additional information.

The SMT section provides signaling information (including IP accessinformation) of all services in an ensemble that includes the SMTsection. Therefore, the reception system can provide a service desiredby the user to the user by accessing an IP stream component belonging tothe desired service using the information parsed from the SMT.

If the service is an NRT service, access information of a FLUTE sessionthat carries the content/files can extract from the SMT.

The information parsed from the SMT is collected by the service manager2122 and is then stored in the first storage unit 2124. The servicemanager 2122 stores the information extracted from the SMT in the firststorage unit 2124 in a service map and guide data format.

That is, the service manager 2122 uses the signaling informationcollected from each of the FIC handler 2121 and the service signalinghandler 2123, so as to configure a service map. Thereafter, the servicemanager 2122 uses a service guide (SG) collected from the service guide(SG) handler 2165 so as to draw up a program guide. Then, the servicemanager 2122 controls the baseband controller 2119 so that a user canreceive (or be provided with) a user-requested mobile service byreferring to the service map and service guide. Furthermore, the servicemanager 2122 may also control the system so that the program guide canbe displayed on at least a portion of the display screen based upon theuser's input.

If the NRT service is described in the SMT through the control of theoperation controller 2100, the service manager 2122 extractsNRT_service_info_descriptor, shown in FIG. 14, from the service loop andreceives the service information of the NRT service which areapplication type and additional requirement information. Also, theservice type of the NRT service is indicated in the NRT service guideoutput display through the presentation manager 2170. Further, using theother fields of the NRT_service_info_descriptor, detailed information ofthe NRT service is displayed. When the NRT service is displayed, if thecontrolled_rendering_flag field value is 1 then the NRT service isdisplayed in a sub-screen using the target_window_position_horizontalfield, target_window_position_vertical field,target_window_length_horizontal field, and target_window_length_verticalfield. If the application type of the NRT service is not supported bythe current broadcast receiver, the information is displayed to the userthrough On Screen Display (OSD) so the user can know about it.

If the application type is Maintenance Data or Targeted

Advertisement, download can be performed without user interruptiontherefore, the NRT service can be omitted when the guide is outputted.

The service manager 2122 controls the handling of the NRT serviceaccording to the service information acquired fromNRT_service_info_descriptor( ). For example, assume that theapplication_type field value is 3, meaning that it is a targetedadvertisement, and user_control_flag field value is ‘1.’ In such a caseit is not possible to arbitrarily delete the NRT service. Also, if theexpiration period for playback is limited to 2 for the expiration_typeand expiration_value field value, the NRT service is automaticallydeleted if it is played twice.

The first storage unit 2124 stores the service map and service guidedrawn up by the service manager 2122. Also, based upon the requests fromthe service manager 2122 and the EPG manager 2171, the first storageunit 2124 extracts the required data, which are then transferred to theservice manager 2122 and/or the EPG manager 2171.

The baseband controller 2119 receives the known data place informationand TPC data, thereby transferring M/H frame time information,information indicating whether or not a data group exists in a selectedparade, place information of known data within a corresponding datagroup, power control information, and so on to each block within thebaseband processor 2110. The TPC data will be described in detail in alater.

Meanwhile, according to the present invention, the transmitting systemuses RS frames by encoding units. Herein, the RS frame may be dividedinto a primary RS frame and a secondary RS frame. However, according tothe embodiment of the present invention, the primary RS frame and thesecondary RS frame will be divided based upon the level of importance ofthe corresponding data.

The primary RS frame decoder 2116 receives, as an input, the output ofthe block decoder 2115. Here, in an embodiment, the primary RS framedecoder 2116 receives mobile service data or NRT service data, which hasbeen encoded through Reed Solomon (RS) encoding and/or Cyclic RedundancyCheck (CRC) encoding, from the block decoder 2115. The primary RS framedecoder 2116 may also receive SMT section data or OMA BCAST SG data,which has been encoded through Reed Solomon (RS) encoding and/or CyclicRedundancy Check (CRC) encoding, from the block decoder 2115.

That is, the primary RS frame decoder 2116 receives data that is notmain service data, for example, at least one of mobile service data, NRTservice data, SMT section data, and OMA BCAST SG data.

The primary RS frame decoder 2116 performs inverse processes of an RSframe encoder (not shown) included in the digital broadcast transmittingsystem, thereby correcting errors existing within the primary RS frame.More specifically, the primary RS frame decoder 2116 forms a primary RSframe by grouping a plurality of data groups and, then, correct errorsin primary RS frame units. In other words, the primary RS frame decoder2116 decodes primary RS frames, which are being transmitted for actualbroadcast services. The primary RS frame decoded by the primary RS framedecoder 2116 outputs to the primary RS frame buffer 2131. The primary RSframe buffer 2131 buffers the primary RS frame, and then configures anM/H TP in each row unit. The M/H TPs of the primary RS frame outputs tothe TP handler 2133.

Additionally, the secondary RS frame decoder 2117 receives, as an input,the output of the block decoder 2115. Herein, in an embodiment, thesecondary RS frame decoder 2117 receives mobile service data or NRTservice data, which has been encoded through Reed Solomon (RS) encodingand/or Cyclic Redundancy Check (CRC) encoding, from the block decoder2115. The secondary RS frame decoder 2117 may also receive SMT sectiondata or OMA BCAST SG data, which has been encoded through Reed Solomon(RS) encoding and/or Cyclic Redundancy Check (CRC) encoding, from theblock decoder 2115.

That is, the secondary RS frame decoder 2117 receives data that is notmain service data, for example, at least one of mobile service data, NRTservice data, SMT section data, and OMA BCAST SG data.

The secondary RS frame decoder 2117 performs inverse processes of an RSframe encoder (not shown) included in the digital broadcast transmittingsystem, thereby correcting errors existing within the secondary RSframe. More specifically, the secondary RS frame decoder 2117 forms asecondary RS frame by grouping a plurality of data groups and, then,correct errors in secondary RS frame units. In other words, thesecondary RS frame decoder 2117 decodes secondary RS frames, which arebeing transmitted for actual broadcast services. The secondary RS framedecoded by the secondary RS frame decoder 2117 outputs to the secondaryRS frame buffer 2132. The secondary RS frame buffer 2132 buffers thesecondary RS frame, and then configures an M/H TP in each row unit. TheM/H TPs of the secondary RS frame outputs to the TP handler 2133.

The TP handler 2133 consists of a TP buffer and a TP parser. The TPhandler 2133 buffers the M/H TPs inputted from the primary RS framebuffer 2131 and the secondary RS frame buffer 2132, and then extractsand analyzes each header of the buffered M/H TPs, thereby recovering IPdatagram from each payload of the corresponding M/H TPs. The recoveredIP datagram is outputted to the IP datagram handler 2141.

The IP datagram handler 2141 consists of an IP datagram buffer and an IPdatagram parser. The IP datagram handler 2141 buffers the IP datagramdelivered from the TP handler 2133, and then extracts and analyzes aheader of the buffered IP datagram, thereby recovering UDP datagram froma payload of the corresponding IP datagram. The recovered UDP datagramis outputted to the UDP datagram handler 2143.

If the UDP datagram is scrambled, the scrambled UDP datagram isdescrambled by the descrambler 2142, and the descrambled UDP datagram isoutputted to the UDP datagram handler 2143. For example, when the UDPdatagram among the received IP datagram is scrambled, the descrambler2142 descrambles the UDP datagram by inputting an encryption key and soon from the service protection stream handler 2146, and outputs thedescrambled UDP datagram to the UDP datagram handler 2143.

The UDP datagram handler 2143 consists of an UDP datagram buffer and anUDP datagram parser. The UDP datagram handler 2143 buffers the UDPdatagram delivered from the IP datagram handler 2141 or the descrambler2142, and then extracts and analyzes a header of the buffered UDPdatagram, thereby recovering data transmitted through a payload of thecorresponding UDP datagram. If the recovered data is an RTP/RTCPdatagram, the recovered data is outputted to the RTP/RTCP datagramhandler 2144. If the recovered data is also an NTP datagram, therecovered data is outputted to the NTP datagram handler 2145.Furthermore, if the recovered data is a service protection stream, therecovered data is outputted to the service protection stream handler2146. And, if the recovered data is an ALC/LCT stream, the recovereddata is outputted to the ALC/LCT steam handler 2148. Also, when therecovered data is SMT section data, the recovered data output to theservice signaling section handler 2123.

Since the SMT section or the service signaling channel that carries theSMT section is an IP datagram having a well-known IP destination addressand a well-known destination UDP port number, the IP datagram handler2141 and the UDP datagram handler 2143 can output data including the SMTsection to the service signaling section handler 2123 without requiringadditional information.

The RTP/RTCP datagram handler 2144 consists of an RTP/RTCP datagrambuffer and an RTP/RTCP datagram parser. The RTP/RTCP datagram handler2144 buffers the data of RTP/RTCP structure outputted from the UDPdatagram handler 2143, and then extracts A/V stream from the buffereddata, thereby outputting the extracted A/V stream to the A/V decoder2161.

The A/V decoder 2161 decodes the audio and video streams outputted fromthe RTP/RTCP datagram handler 2144 using audio and video decodingalgorithms, respectively. The decoded audio and video data is outputtedto the presentation manager 2170. Herein, at least one of an AC-3decoding algorithm, an MPEG 2 audio decoding algorithm, an MPEG 4 audiodecoding algorithm, an AAC decoding algorithm, an AAC+ decodingalgorithm, an HE AAC decoding algorithm, an AAC SBR decoding algorithm,an MPEG surround decoding algorithm, and a BSAC decoding algorithm canbe used as the audio decoding algorithm and at least one of an MPEG 2video decoding algorithm, an MPEG 4 video decoding algorithm, an H.264decoding algorithm, an SVC decoding algorithm, and a VC-1 decodingalgorithm can be used as the audio decoding algorithm.

The NTP datagram handler 2145 consists of an NTP datagram buffer and anNTP datagram parser. The NTP datagram handler 2145 buffers data havingan NTP structure, the data being outputted from the UDP datagram handler2143. Then, the NTP datagram handler 2145 extracts an NTP stream fromthe buffered data. Thereafter, the extracted NTP stream is outputted tothe A/V decoder 2161 so as to be decoded.

The service protection stream handler 2146 may further include a serviceprotection stream buffer. Herein, the service protection stream handler2146 buffers data designated (or required) for service protection, thedata being outputted from the UDP datagram handler 2143. Subsequently,the service protection stream handler 2146 extracts information requiredfor descrambling from the extracted data. The information required fordescrambling includes a key value, such as SKTM and LKTM. Theinformation for descrambling is stored in the second storage unit 2147,and, when required, the information for descrambling is outputted to thedescrambler 2142.

The ALC/LCT stream handler 2148 consists of an ALC/LCT stream buffer andan ALC/LCT stream parser. And, the ALC/LCT stream handler 2148 buffersdata having an ALC/LCT structure, the data being outputted from the UDPdatagram handler 2143. Then, the ALC/LCT stream handler 2148 analyzes aheader and a header expansion of an ALC/LCT session from the buffereddata. Based upon the analysis result of the header and header expansionof the ALC/LCT session, when the data being transmitted to the ALC/LCTsession correspond to an XML structure, the corresponding data areoutputted to an XML parser 2150. Alternatively, when the data beingtransmitted to the ALC/LCT session correspond to a file structure, thecorresponding data are outputted to a file decoder 2162. At this point,when the data that are being transmitted to the ALC/LCT session arecompressed, the compressed data are decompressed by a decompressor 2149,thereby being outputted to the XML parser 2150 or the file decoder 2162.

The XML parser 2150 analyses the XML data being transmitted through theALC/LCT session. Then, when the analyzed data correspond to datadesignated to a file-based service such as NRT service, the XML parser2150 outputs the corresponding data to the FDT handler 2151. On theother hand, if the analyzed data correspond to data designated to aservice guide, the XML parser 2150 outputs the corresponding data to theSG handler 2165. The FDT handler 2151 analyzes and processes a filedescription table of a FLUTE protocol, which is transmitted in an XMLstructure through the ALC/LCT session.

The SG handler 2165 collects and analyzes the data designated for aservice guide, the data being transmitted in an XML structure, therebyoutputting the analyzed data to the service manager 2122.

The file decoder 2162 decodes the data having a file structure and beingtransmitted through the ALC/LCT session, thereby outputting the decodeddata to the middleware engine 2164 or storing the decoded data in athird storage unit 2163. In an embodiment the decoded file structureddata in the File Decoder 2162 includes NRT service data.

Herein, the middleware engine 2164 translates the file structure data(i.e., the application) such as NRT service and executes the translatedapplication. Thereafter, the application may be outputted to an outputdevice, such as a display screen or speakers, through the applicationpresentation manager 2170. According to an embodiment of the presentinvention, the middleware engine 2164 corresponds to a JAVA-basedmiddleware engine.

Based upon a user-input, the EPG manager 2171 receives EPG data eitherthrough the service manager 2122 or through the SG handler 2165, so asto convert the received EPG data to a display format, thereby outputtingthe converted data to the presentation manager 2170.

The application manager 2172 performs overall management associated withthe processing of application data (i.e., NRT service data), which arebeing transmitted in object formats, file formats, and so on.Furthermore, based upon a user-command inputted through the UI manager2173, the operation controller 2100 controls at least one of the servicemanager 2122, the EPG manager 2171, the application manager 2172, andthe presentation manager 2170, so as to enable the user-requestedfunction to be executed.

The UI manager 2173 transfers the user-input to the operation controller2100 through the UI.

Finally, the presentation manager 2170 provides at least one of theaudio and video data being outputted from the A/V decoder 2161 and theEPG data being outputted from the EPG manager 2171 to the user throughthe speaker and/or display screen.

According to the present invention, the method of processing an NRTservice and broadcast receiver includes signaling service informationincluding service type and detail information of service type of an NRTservice in the signaling information table so the broadcast receiver isable to handle various use case. The broadcast receiver can efficientlyprocess the NRT service by using the signaled service information in thesignaling information table for various codec combinations according tothe NRT use case such as targeted advertisement, music download, andpush VOD, and also for hardware module within the connected broadcastreceiver and various storage and playback scenarios.

The present invention is not limited to the above embodiments and itwill be apparent to those skilled in the art that various modificationscan be made to in the present invention as can be seen from the appendedclaims and such modifications are included in the scope of theinvention.

1-18. (canceled)
 19. A method of transmitting a non-real time service,the method comprising: generating first signaling data containingservice-level attributes for a non-real time service and secondsignaling data including a service fragment and a content fragment of aservice guide for the non-real time service; generating IP datagramscontaining one or more non-real time services, the first signaling dataand the second signaling data; and generating and transmitting abroadcast signal including the IP datagrams, wherein: the non-real timeservice is delivered in advance of its use and stored in a receivingdevice and associated with one or more content items, the content itemis composed of one or more files being delivered via a File Deliveryover Unidirectional Transport (FLUTE) file delivery session, the servicefragment includes an element indicating that the service fragmentcontains information regarding the identified non-real time service, andthe content fragment includes a linkage element linking from a contentitem to one or more files, the linkage element having an identifier ofthe content item, the identifier of the content item being used to mapone or more files to the content item with a content identifier includedin a FLUTE File Description Table (FDT) instance for the non-real timeservice.
 20. The method of claim 19, further comprising: generatingthird signaling data containing Fast Information Channel (FIC) dataproviding fast service acquisition at the receiving device; andgenerating fourth signaling data containing Transmission ParameterChannel (TPC) data which includes parameters used in a physical layermodule.
 21. The method of claim 20, wherein the NRT service is signaledbased on a hierarchy among the first signaling data, the third signalingdata and fourth signaling data.
 22. The method of claim 21, wherein thelinkage element of the content fragment includes information indicatingan attribute that identifies the file as an entry point of the contentitem identified by the parameter, the entry point is presented initiallythe file of the content item by the receiving device.
 23. An apparatusof transmitting a non-real time service, the apparatus comprising: aprocessor configured to generate first signaling data containingservice-level attributes for a non-real time service, second signalingdata including a service fragment and a content fragment of a serviceguide for the non-real time service, and IP datagrams containing one ormore non-real time services, the first signaling data and the secondsignaling data; and a transmitter configured to transmit a broadcastsignal including IP datagrams, wherein: the non-real time service isdelivered in advance of its use and stored in a receiving device andassociated with one or more content items, the content item is composedof one or more files being delivered via a File Delivery overUnidirectional Transport (FLUTE) file delivery session, the servicefragment includes an element indicating that the service fragmentcontains information regarding the identified non-real time service, andthe content fragment includes a linkage element linking from a contentitem to one or more files, the linkage element having an identifier ofthe content item, the identifier of the content item being used to mapone or more files to the content item with a content identifier includedin a FLUTE File Description Table (FDT) instance for the non-real timeservice.
 24. The apparatus of claim 23, wherein the processor furthergenerates: third signaling data containing Fast Information Channel(FIC) data providing fast service acquisition at the receiving device;and fourth signaling data containing Transmission Parameter Channel(TPC) data which includes parameters used in a physical layer module.25. The apparatus of claim 24, wherein the NRT service is signaled basedon a hierarchy among the first signaling data, the third signaling dataand fourth signaling data.
 26. The apparatus of claim 25, wherein thelinkage element of the content fragment includes information indicatingan attribute that identifies the file as an entry point of the contentitem identified by the parameter, the entry point is presented initiallythe file of the content item by the receiving device.